Portal | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref

 Difference between areas set to pointers Goto page 1, 2  Next
Author Message
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Jul 30, 2011 1:28 pm    Post subject: Difference between areas set to pointers 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)?

Bill Woodger

Moderator Emeritus

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

Posted: Sat Jul 30, 2011 1:41 pm    Post subject: Re: Difference between areas set to pointers

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

Moderator Emeritus

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

Posted: Sat Jul 30, 2011 2:21 pm    Post subject:

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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Jul 30, 2011 2:27 pm    Post subject: Reply to: Difference between areas set to pointers 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Jul 30, 2011 2:30 pm    Post subject: 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.
dick scherrer

Moderator Emeritus

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

 Posted: Sat Jul 30, 2011 2:32 pm    Post subject: Hello, What reason is there to NOT put this into some prototype code and move forward. . . Obviously, there is something i am missing.
Bill Woodger

Moderator Emeritus

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

Posted: Sat Jul 30, 2011 3:04 pm    Post subject:

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

Global Moderator

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

 Posted: Sat Jul 30, 2011 3:25 pm    Post subject: 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 theSET TO ADDRESS OF SET TO 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.
Bill Woodger

Moderator Emeritus

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

Posted: Sat Jul 30, 2011 3:56 pm    Post subject: Reply to: Difference between areas set to pointers

 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Aug 06, 2011 12:32 pm    Post subject: 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.
Bill Woodger

Moderator Emeritus

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

Posted: Sat Aug 06, 2011 1:44 pm    Post subject:

 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?
dbzTHEdinosauer

Global Moderator

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

 Posted: Sat Aug 06, 2011 2:33 pm    Post subject: 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 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Aug 06, 2011 4:18 pm    Post subject: 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.
Bill Woodger

Moderator Emeritus

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

 Posted: Sat Aug 06, 2011 4:36 pm    Post subject: Reply to: Difference between areas set to pointers 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Aug 06, 2011 4:53 pm    Post subject: No in controller program a working storage area has been set to pointer. SET POINTER-FIELD TO ADDRESS OF WS-FIELD.
Bill Woodger

Moderator Emeritus

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

 Posted: Sat Aug 06, 2011 5:02 pm    Post subject: Reply to: Difference between areas set to pointers 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

 Posted: Sat Aug 06, 2011 5:10 pm    Post subject: 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.
dbzTHEdinosauer

Global Moderator

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

 Posted: Sat Aug 06, 2011 5:23 pm    Post subject: 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........
Bill Woodger

Moderator Emeritus

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

 Posted: Sat Aug 06, 2011 5:26 pm    Post subject: 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.
niks_jude
Warnings : 1

Active User

Joined: 01 Dec 2006
Posts: 144
Location: Mumbai

Posted: Sat Aug 06, 2011 5:31 pm    Post subject: Reply to: Difference between areas set to pointers

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.
 All times are GMT + 6 HoursGoto page 1, 2  Next
 Page 1 of 2

Search our Forum:

 Topic Author Forum Replies Posted Similar Topics Difference between CEE3250C and CEE3204S josephineyeow COBOL Programming 2 Mon Sep 21, 2020 8:19 pm Difference between sysexec and sysproc Renato Zangerolami CLIST & REXX 6 Mon Feb 10, 2020 9:31 pm Difference between DATACLAS=MULTIVOL ... rohanthengal JCL & VSAM 10 Mon Nov 25, 2019 4:09 pm Difference between CICS region bounce... polymathtarun CICS 3 Sun Aug 04, 2019 10:51 pm Difference between GE and GB return c... Poha Eater IMS DB/DC 8 Fri Jul 12, 2019 12:59 pm

 © 2003-2020 IBM MAINFRAME Software Support Division
 Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us