Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

How to reduce the load modulesize of a cics-cobol program?
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 4:24 pm    Post subject: How to reduce the load modulesize of a cics-cobol program?
Reply with quote

Hi,

In my project, a transaction is utilizing the CICS memory (>30MB), since from the main program the Copy books of called variable is large in size. so far i have analysed the following techniques to reduce the load size

1.unused working variables.
2.using 'Depending on clause'(since we are passing cobol tables in call statement)
3.unused linkage variables.
4.replacing linkage variables by channels and containers(instead of passing the data through linkage,data is written in main program and browsed in sub program,call statement will be used to transfer the control to sub program).

Please let me know is there any points can be added with this approach mentioned above. Also i am not aware that how the particular transaction consumes more than 32MB CICS storage.

Thanks,
Mural.
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 5:04 pm    Post subject:
Reply with quote

1.unused working variables. good idea
2.using 'Depending on clause'(since we are passing cobol tables in call statement) waste of time
3.unused linkage variables.good idea,but will not impact invoking module size
4.replacing linkage variables by channels and containers(instead of passing the data through linkage,data is written in main program and browsed in sub program,call statement will be used to transfer the control to sub program).waste of time - which module's size do you want to reduce

changing linkage items will only reduce the invoker's size. and if the task needs the data/storage, the data/storage will have to be supplied from somewhere.

you need to better analyze your process. still confused about all this data,
where does it come-from? why is it needed.
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 5:26 pm    Post subject:
Reply with quote

Dick Brenholtz,




Quote:

waste of time - which module's size do you want to reduce


Assume, i have 10 modules under one transaction i.e., Program A is the main program -B is the sub program of Program-A and main program for Program-C, it continues till Program-J(10th module). I want to reduce the total CICS memory size utilized by the transaction involving program-A to Program-J.



Quote:

where does it come-from? why is it needed.


The requirement came because the cics team analysed the old transaction,say for example TR10, (it utilizes >10MB <15MB), a new project with some business modification is done for TR10 which was named as TR11 which utilizes around 30MB. This analysis is for new transaction which causes CICS memory utilization around 30 MB.

To add with the above approach,
will BLL help to reduce the load/memory size?. So far i didn't experienced using BLL or address pointers.Please confirm.

Thanks,
murali.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Mon Aug 30, 2010 6:01 pm    Post subject:
Reply with quote

Quote:
will BLL help to reduce the load/memory size?
No.

Where is all the memory being used?

How do the modules get invoked?

A problem of this nature requires, most of the time, a complete rewrite of the application to reduce memory requirements -- tweaking how the program accesses memory won't affect how much memory is being used.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 6:02 pm    Post subject:
Reply with quote

hey, I don't care if the storage is allocated by virtue of loading a module
or by getmain.

acquired storage is acquired storage.

you still have not explained (in detail) what requirements exist.

are these web applications?

is your communication to submodules via LINK or XCTL?

your explanations and arguments are based on generalities.
no one can respond to such.
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 6:12 pm    Post subject:
Reply with quote

The modules are invoked after data is pooled into MQ from webservice, which inturn intiates the transaction. once the transaction is invoked the program-a passes data after formatting to program-B using
Dynamic COBOL CALL statement, LINK/XCTL is not used since the data size exceeds 32k.

Please let me know your suggestions.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Aug 30, 2010 6:25 pm    Post subject: Reply to: How to reduce the load modulesize of a cics-cobol
Reply with quote

As strange as this may sound, when you specify the OPT compile option, the load module size can actually increase.

This is because redundant code (EG: PERFORM logic of the same routine) is copied in-line, resulting in more of a top/down logic flow. This is meant to reduce paging.

There are benefits, which calculate variables during compilation as opposed to execution, the use of more efficient instructions (IE: Use of XC instructions as opposed to a CLI/CLC to clear variables to X'00's), etc.

Is the program issuing any explicit non-Shared GETMAIN's? Does the program issue an explicit FREEMAIN when it's done with the storage. Note: If the logic is near the point of task termination, then don't bother.

Does it issue any GETMAIN SHARED API's and not issue an explicit FREEMAIN?

Does this program access any sub-program's? Are they accessed via a CALL or LINK? Are there any STATIC CALL's where the sub-program has a large amount of non-reentrant WS? If Dynamic-Calls are issued, keep in mind that the WS of the CALLED sub-program is not freed until task termination as it's considerd by LE to be within the same Enclave. This wouldn't happen with a LINK-API as the sub-program's WS is freed upon return to the LINKER (Enclave change).

As Robert has suggested, perhaps you've reached a point in time when a redesign is inevitable?

Bill
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 6:46 pm    Post subject:
Reply with quote

what version of CICS are you running?

what version of COBOL are you using?
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 6:48 pm    Post subject:
Reply with quote

GETMAIN/FREE Main is not used in this project. Dynamic Call is used for sub-program access.

Please let me know what are all required to redesign & approach?

Thanks,
Murali.
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 6:49 pm    Post subject:
Reply with quote

Dick Brenholtz

Quote:

what version of CICS are you running?

what version of COBOL are you using?




CICS-3.2
COBOL-VS COBOL II

Thanks,
Murali.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Aug 30, 2010 7:12 pm    Post subject: Reply to: How to reduce the load modulesize of a cics-cobol
Reply with quote

How much WS exists in the Dynamically-Called sub-programs? If it's a significant part of the 32MB, then this may be the (or one of the) smoking guns?

I understand you're using them because the data-length exceeds 32763?

I'm not an advocate (and neither is IBM) of passing addresses, but could this be a last-resort consideration? Although, you could run into addressability issues between AMODE/RMODE.

Bill
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 7:17 pm    Post subject:
Reply with quote

Quote:
Please let me know what are all required to redesign & approach?


Since you are communicating via MQS,
make this 'should have been batch in the first place'
a BATCH application.

you can either
  • use the trigger mechanism to invoke the module in batch,as you are doing in CICS
  • or better - design a permanent running batch job (started task), that would query the queue and process the transaction


we wrote a batch application that would communicate to SAP (on a server) via MQS and drove 1 million trans per hour - very large memory foot print.

you can use the WAIT parm with Quiese on the read queue and when there are no messages, the batch job just waits on mqs without spinning any cycles.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 7:20 pm    Post subject:
Reply with quote

Bill,

one of the problems of passing addresses, is that VS COBOL and COBOL II
do not lend themselves easily to 'SET Pointer (in WS) to DATA-area (in WS).
you would need another module to load the pointer with the address.
though a migration to enterprise cobol would change that.
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 7:27 pm    Post subject:
Reply with quote

Bill,

If i use channels & containers, there will be a chance of reducing the memory utilization i guess. But storage of Ws- variable can't be avoided,but passing it through address can be ignored?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Aug 30, 2010 7:34 pm    Post subject: Reply to: How to reduce the load modulesize of a cics-cobol
Reply with quote

Dick,

Many moons ago and in a former life, we used small callable sub-programs, VS/COBOL II and Assembler, passing two parms, a data-area and a pointer.

When the sub-program gained control, it would set the pointer to the address of the data-area. Yes, a little more difficult in OS/VS COBOL. so the Assembler version was used.

We kept these sub-programs around until OS/390 COBOL 2.2, when we could use the SET POINTER facility of other than 01 and 77 LINKAGE items.

Bill
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Mon Aug 30, 2010 7:37 pm    Post subject:
Reply with quote

again, I ask:

Why does this need to be a CICS application?

IMUO, you are just trying to fix a poorly designed system with
rubber-bands and bailing wire.

If you have a need for >32k, how are you going to reduce that requirement?

it does not matter if you use channels, containers, buckets or db2.
the memory requirement will not change.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Aug 30, 2010 7:38 pm    Post subject: Reply to: How to reduce the load modulesize of a cics-cobol
Reply with quote

One benefit in using Channels and Containers, is that they use 64-Bit Storage (above the bar).

This requires that the TS 3.2 region be allocated (at a minimum), 2 GB of above the bar storage at installation time, which is what is recommended by IBM in their installation doc.

Bill
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 8:02 pm    Post subject:
Reply with quote

Bill,

Can you please explain more specific how when 'OPT' compiler option increase the load module size?

Thanks,
Murali.
Back to top
View user's profile Send private message
pkmurali
Warnings : 1

Active User


Joined: 15 Dec 2005
Posts: 236

PostPosted: Mon Aug 30, 2010 8:11 pm    Post subject:
Reply with quote

Dick,


You are right.
Quote:

IMUO, you are just trying to fix a poorly designed system with
rubber-bands and bailing wire.


But i am analyzing is there any possibilty to reduce the size, if all the approach doesn't holds good then only i can say this system is poor.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Mon Aug 30, 2010 8:23 pm    Post subject: Reply to: How to reduce the load modulesize of a cics-cobol
Reply with quote

Let's say you have a PERFORMED routine that get's performed in many places within the load module. When NOOPT is specified, each time the routine is PERFORMED, it basically issues a BAL instruction from the point in the program where the perform is issued. If the performed routine is outside of the current MVS page, then a page fault occurs and the page which contains the PERFORMED routine is loaded for execution.

If you use OPT, the PERFORMED routine is copied in-line and avoids the BAL and possible page-fault.

If the routine is PEFORMED 1000 times and each PERFORM is copied in-line, you can see how the load-module size can increase. But, the result is less page-faults and more top/down execution.

Bill
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts CICS START AND CANCEL blayek CICS 1 Wed Dec 07, 2016 3:27 am
No new posts I can not compile my program PL1 V3.R... Miguel Fernandez PL/I & Assembler 13 Tue Dec 06, 2016 8:30 pm
No new posts How does a called pgm know if its cal... Graeme Westerman COBOL Programming 4 Tue Nov 29, 2016 9:25 pm
No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
No new posts CICS Roll back partially - Need to re... dwijadas CICS 4 Wed Nov 16, 2016 4:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us