IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Difference between areas set to pointers


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Jul 30, 2011 1:28 pm
Reply with quote

We are in analysis phase for some retrofits so I am unable to test this.

Suppose program A, B and C call program Z, to build some data-area.

Program A calls program Z to build the data-area and sets this area's pointer to some common pointer.

The common pointer is being passed between programs A,B and C.

Now program B and C set this common pointer to their own data-area and call program Z. Their data-area is bigger than program A, which originally set the pointer.

So will the program B and C receive data area as per their own area length or limited by the one set by program A?

I mean can A,B,C point to the same common pointer but have their own areas of different lengths (pointing to this pointer)?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jul 30, 2011 1:41 pm
Reply with quote

niks_jude wrote:
We are in analysis phase for some retrofits so I am unable to test this.

Suppose program A, B and C call program Z, to build some data-area.

Program A calls program Z to build the data-area and sets this area's pointer to some common pointer.

The common pointer is being passed between programs A,B and C.

Now program B and C set this common pointer to their own data-area and call program Z. Their data-area is bigger than program A, which originally set the pointer.

So will the program B and C receive data area as per their own area length or limited by the one set by program A?

I mean can A,B,C point to the same common pointer but have their own areas of different lengths (pointing to this pointer)?


I don't get being "in analysis" precluding checking out something you'd like an answer to yourself...

You haven't supplied enough, or sufficiently clear, information for an answer.

How is Z allocating the storage?

Do B and C set the pointer, or set some area in the Linkage section to the value of the pointer?

Do B and C call Z with the pointer which is defined by A?

When you answer these, there will be more questions unless you manage to cover those seperately to the specific answers. Maybe you get the idea about what else is needed once these are known.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sat Jul 30, 2011 2:21 pm
Reply with quote

Hello,

Quote:
We are in analysis phase for some retrofits so I am unable to test this.
Sure you can. . . I suspect there is a compiler available on the system.

Just write a bit of experimental code and you can learn. If there are questions/problems with this experimental code, someone here may have a suggestion. . .

I strongly recommend this learing be done before someone commits to deliverables that require a new (to your application) methodology such as this.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Jul 30, 2011 2:27 pm
Reply with quote

Sorry for not being clear. I will try to put it up with much more clarity.

A has the area defined in working storage, sets it to a common pointer and passes just the pointer (defined as USAGE POINTER) to program Z.

B and C do the same thing. And the pointer is same as that pointed by A.

This pointer is present in a common copybook used by A,B,C and Z.

Z sets the pointer to its own area, populates data and assumes A,B and C will get the data by pointing to this pointer.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Jul 30, 2011 2:30 pm
Reply with quote

I mean I am unable to test as this load module calls around 400 programs.
And we will have to do recompiles, compiles and links as we have around 80 copybooks as of now. We are retrofitting copybooks and source separately.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Sat Jul 30, 2011 2:32 pm
Reply with quote

Hello,

What reason is there to NOT put this into some prototype code and move forward. . . icon_confused.gif

Obviously, there is something i am missing.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jul 30, 2011 3:04 pm
Reply with quote

niks_jude wrote:
I mean I am unable to test as this load module calls around 400 programs.
And we will have to do recompiles, compiles and links as we have around 80 copybooks as of now. We are retrofitting copybooks and source separately.



You don't have to use the original names. Copy them to some new name, compile, link, run, no problem.

Edit: you can "stub" them, so they just do the relevant stuff for your investigation...
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Jul 30, 2011 3:25 pm
Reply with quote

niks_jude,

what your are resisting (and everybody is suggesting your do)
is to learn the rules about passing addresses.

that no one at your site seems experienced enough to lay down a design for this rather basic concept is rather incredulous (and scary).

but since I have been slammed by rookies with 16 X 1 year experience lately,
I will provide a little info.
digest that and then come back for more.

the programmers guide provides an excellent description and explanation of this concept (including diagrams and pictures) which I will not attempt in this missage.

A POINTER contains an address.
it is populated by the
  • SET <pointer> TO ADDRESS OF <data-area>
  • SET <pointer> TO <pointer>
SET instruction formats.

An area defined in the LINKAGE SECTION receives ADDRESSABLILTY via the above is a summary of the SET statement

This is the discussion in the Programmers Guide about 4.2 Sharing data.

basic rule:
data definitions in linkage of CALLed programs
should be the same as the definitions in WORKING-STORAGE of the CALLing programs.
use copybooks in both CALLing and CALLed programs
There are cute tricks that can be employed to access data beyond,
but these are based on laziness and are dangerous.
In todays world, it does not take long to recompile/relink/rebind 1000 modules.
Make the effort to make everything clean and obvious and you won't have problems.


after reading the above, I am sure that if you have any questions
many members will be able to help.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Jul 30, 2011 3:56 pm
Reply with quote

niks_jude wrote:
Sorry for not being clear. I will try to put it up with much more clarity.

A has the area defined in working storage, sets it to a common pointer and passes just the pointer (defined as USAGE POINTER) to program Z.

B and C do the same thing. And the pointer is same as that pointed by A.

This pointer is present in a common copybook used by A,B,C and Z.

Z sets the pointer to its own area, populates data and assumes A,B and C will get the data by pointing to this pointer.


It might not all be down to you. If I am following this, the programs are doing something confusing.

I assume this is existing code which you need to know exactly how it operates? Any documentation? Specs? Even comments in the programs?

Trying for clarity on the situation you as you are describing:

Code:
A
w-s
01  wsA-data-area pic x.
01  wsA-data-area-pointer, usage pointer

B
w-s
01  wsB-data-area pic x.
l s
01  lB-data-area-pointer, usage pointer (located in A)

C
w-s
01  wsC-data-area pic x.

l s01  lC-data-area-pointer, usage pointer (located in A)

Z
w-s
01  wsZ-data-area pic x.
l s
01  lZ-data-area-pointer, usage pointer (located in A)


This seems to be how you describe it so far.

If so, with no storage maps (by ordinary Cobol data definitions) in Linkage Sections then you are not going to be able to get access to data across the modules. The whole pointer thing would be... pointless.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Aug 06, 2011 12:32 pm
Reply with quote

Sorry guys, was off to somewhere else so could not respond.

Now I can say is that things are more clear.

My basic question if i can sum up now is - if we pass working storage variable to a program (the called program will have it defined in the linkage section), then the area allocated would depend on the working storage field length rather than linkage section area length. Because linkage section variables do not have any allocations of their own, atleast in call by reference.

In my case, only difference was, the pointers were involved.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 1:44 pm
Reply with quote

niks_jude wrote:
Sorry guys, was off to somewhere else so could not respond.

Now I can say is that things are more clear.

My basic question if i can sum up now is - if we pass working storage variable to a program (the called program will have it defined in the linkage section), then the area allocated would depend on the working storage field length rather than linkage section area length. Because linkage section variables do not have any allocations of their own, atleast in call by reference.

In my case, only difference was, the pointers were involved.


Getting there.

Cobol does no match-up between the size define in the caller and the size defined in the called, or even between the options of the USING (reference etc). Things have to "line-up" to stand a chance of working (third in called using must be third in procedure division using, for instance).

There are techniques for accessing data that is defined elsewhere. For storage defined in the main program, or any program where the data is required in a "lower-down-the-chain" program, the technique is simple. Call using/procedure division using. Nothing else is needed.

Your example I don't understand, and don't understand why it used pointers. Is it an existing thing?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Aug 06, 2011 2:33 pm
Reply with quote

unless a CALLed module is CANCELed by its CALLer upon return,
subsequent CALLs to the submodule will find the WORKING-STORAGE in a 'last used state'.
this is very handy when you perform all your DASD or TAPE IO in a CALLed module.

Using a STRUCTURE composed of POINTERS is a handy way of passing data to sub-modules (as well as 'upper modules').

was involved in the development of a 'small' system around 2000
that involved 200 or so sub-modules that effectively had no WORKING-STORAGE.
Even DB2 modules used Linkage for host variables,
even though they were CALLed from many different modules
since the memory addressed by the LINKAGE was the same: storage definition module (see below)

had 8 RUN-UNITs,
each of which used many of the sub-modules,
but none used all,
and few used the same combination.

The USING phrase for PROCEDURE DIVISION and CALL
was the same for everybody:
CONTROL-AREA
RESPONSE-AREA
POINTER-AREA.

The POINTER-AREA structure was defined (in a copybook) and contained some 120 POINTERs.
The MainModule of each RUN-UNIT CALLed its own storage definition module,
which initialized the areas needed for that RUN-UNIT and loaded the address of each area to its corresponding POINTER.

Other than CONTROL-AREA and RESPONSE-AREA which was defined in MainModules WORKING-STORAGE,
all of the assigned memory for each RUN-UNIT was contained in the storage definition module.

Each sub-module would SET ADDRESS OF linkage-item TO <corresponding>POINTER.

Using this 'Mainframe PLUG-AND-PLAY" methodology allowed for much flexibility,
and a consistant USING phrase.

Part of the CONTROL-AREA
was a PIC X(08) field with a reference name of MODULE-TO-CALL
and contained some 200 or so Level-88's
which allowed for an easy dynamic CALL methodology.

If a new sub-module which required a new data structure
was added to the RUN-UNIT,
the storage definition module was changed,
a POINTER was added,
a Level-88 was added,
the module that CALLed the new module was modifed,
and the complete system was recompiled/linked/db2-binded
without fear of affecting the system as a whole.

Using POINTERs, a CALLing module can address the storage of a CALLed module.

The same 'PLUG & PLAY' was used with a sub-system CALLed by both batch and CICs. Just had to keep each structure (01-level) to 4K or less.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Aug 06, 2011 4:18 pm
Reply with quote

There are around 200 elements in my load module.

The controller sets the pointer to some WS item, calls a program Z to build an area. In program Z, the area built is set to the pointer address.

Now any program out of these 200 modules, can point to this area by pointing their local area to this pointer. The USING is not needed at all with this technique.

This is what DBZ means I guess with the plug&play in his example.


My question is controller area which it set to the pointer is 200 bytes. In Z suppose I define the area as 400 bytes.

If this is possible, then if other sub-modules point their areas to this common pointer and try to use the area, will they get 200 bytes only or 400 bytes.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 4:36 pm
Reply with quote

In your linkage you can define any size you like. It is not even limited to the amount of storage you allocate in Z...

However, if you want it to work, don't allocate more than is allocated in Z. The point I'm trying to make is that there is no checking on lenghts of storage in linkage as being within the boundary of what you allocate. All that is passed anywhere is the address to something. In the case of pointers, the call passes the address of the pointer which passes an address.

What you can't do is to assign an address to a working-storage field. To use storage which has been allocated somewhere else, and you get to address it via a pointer, you must assign the address to an item in the linkage section. This is what I don't understand about you have outlined your situation originally.

Edit: Looking back at your original, what you refer to as a program's "own" storage, I now assume is in the Linkage Section, and your query is about whether they can be different sizes?

So, don't make them bigger than where the storage is defined. If your storage in linkage is defined bigger in program P than Q, then Q won't be able to know about anything that is in the extended bit which P has.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Aug 06, 2011 4:53 pm
Reply with quote

No in controller program a working storage area has been set to pointer.

SET POINTER-FIELD
TO ADDRESS OF WS-FIELD.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 5:02 pm
Reply with quote

A calls Z with pointer-area.

Z set point-area value to address of item in WS in Z.

A passes pointer set by Z to B and C.

B an C call Z. You have to explain why.

B and C can access the storage in Z just by assinging item in Linkage section to address held in the pointer. They have to need of calling Z to do this, so that is why you need to explain.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Aug 06, 2011 5:10 pm
Reply with quote

A sets the pointer to some working storage.

Now passes pointer to Z. Z makes it linkage section item point to this pointer (please note it does not change the pointer address, it only makes its LS item point to the pointer address).

Now B and C, call C and set their LS items to address of pointer.

Please note that only A has set the address of pointer to its WS item.

B, C and Z have simply set their areas point to this common pointer.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Aug 06, 2011 5:23 pm
Reply with quote

niks_jude,

you are being a little stubborn.

1. the WORKING-STORAGE of pgm-A is addressed by a pointer.

2. in any other program, the linkage definition addressed by that pointer should not exceed the storage defined by the structure in WORKING-STORAGE of pgm-a.

3. if your linkage structure is larger than the working-storage structure,
then you would be addressing (with your commands in the linkage pgm) memory beyond that defined originally in pgm-A.

4. it does not matter if your sub-module uses a USING phrase or a SET pointer, the effect is still the same. The CALLed module only has the begining address of the structure, it does not have a length passed as JAVA and C do. This is COBOL........
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 5:26 pm
Reply with quote

OK, so A is defining the storage.

A calls Z so that Z can tell other things about the storage in A.

B and C call Z. Z gives them the pointer value of the storage in A.

So, A, B and C can all access part of the working-storage in A.

B and C should not define longer storage than is allocated in A. They can, but they shouldn't.

If B defines a greater length in the linkage than C, no problem, as long as C doesn't need the extra storage. And all vice-versa.
Back to top
View user's profile Send private message
niks_jude
Warnings : 1

Active User


Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

PostPosted: Sat Aug 06, 2011 5:31 pm
Reply with quote

Sorry if I sound stubborn, but did not meant to.

This statement sums up what I was looking for -

Quote:
2. in any other program, the linkage definition addressed by that pointer should not exceed the storage defined by the structure in WORKING-STORAGE of pgm-a.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 5:40 pm
Reply with quote

Correct.

The thing is, there nothing but the "people" to check on this. The compiler doesn't care. Linkeditor doesn't care. Etc. Down to the people to keep this straight.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Aug 06, 2011 7:27 pm
Reply with quote

Comparing dbz's set-up to yours, you might be able to benefit from some simplication.

Program A calls Z with a table of pointers.

Z establishes address of all required "shared" storage requirements, putting addresses in relevant entries in table of pointers.

Table of pointers is included in linkage to all modules that A calls.

Modules that A calls, and any subsequent calls, can refer to the data they require without further recourse to Z (by setting relevant linkage to relevant address from table of pointers).
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Timestamp difference and its average ... DB2 11
No new posts Difference when accessing dataset in ... JCL & VSAM 7
No new posts What is the difference between Taskty... Compuware & Other Tools 2
No new posts Difference between VALIDPROC and CHEC... DB2 3
No new posts Difference between CEE3250C and CEE3204S COBOL Programming 2
Search our Forums:

Back to Top