|
View previous topic :: View next topic
|
| Author |
Message |
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
what version of CICS are you running?
what version of COBOL are you using? |
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| 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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
Bill,
Can you please explain more specific how when 'OPT' compiler option increase the load module size?
Thanks,
Murali. |
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
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 |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
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 |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
hey, your cics people have already said that it sucks.
any reason though has not been given to making this a batch application.
since you are COBOL CALLing all the sub-modules it would be a relatively quck conversion - unless of course you included all the cics garbage in the linkage section of these cobol modules. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Dick,
The OP has still not given us an idea of the amount of WS in the CALLED sub-programs.
Mural,
Can you give us the total amount of WS found in the CALLED sub-programs?
Bill |
|
| Back to top |
|
|
pkmurali
Warnings : 1
Active User
Joined: 15 Dec 2005
Posts: 271
|
|
|
|
Bill,
i checked the modules which has compiler option as NOOPTIMIZE.
Dick,
My application is not only used by one system, if i suggest for batch,i have to look for Business functions. mostly my client would reject my proposal if i go with batch option.
Is ther any CICS command to check the CICS memory utilization for a Transaction?
Thanks,
Murali |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
even the title is just plain wrong...
I might agree on something like... reduce the overall storage requirement
reducing the load module size only does not really make any sense IMHO
| Quote: |
| Can you please explain more specific how when 'OPT' compiler option increase the load module size? |
/compiler theory on
there are <generally> two options when optimizing
optimize for speed, optimize for storage
the two things quite too often contradict themselves
optimize for speed usually mean inlining and duplicating code
optimize for storage means calling common subroutines
but even a simple loop can be expanded in different ways according to the optimization required
/approximation on
| Code: |
let' s make an example with a table/array of fixed size
20 fullword that should be initialized with zeroes
optimized for speed
xr reg,reg
st reg,array
st reg,array+4
st reg,array+8
...
st reg,array+76
instructions executed,
setup 1
store 20
total 21
storage
setup 4
store 80
total 84
optimized for storage
la reg1,20
xr reg2,reg2
la reg3,array-4
loop la reg3,4(,r3)
st reg2,0(reg3)
bct r1,loop
instructions executed
setup 3
store 60
total 63
storage used
setup 10
store 12
total 22
|
|
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| pkmurali wrote: |
| then only i can say this system is poor. |
don't get too high-up on your horse, son.
your obvious lack of understanding of basic concepts tends to invalidate any expert-opinion that you may have to offer.
Bill,
I believe the TS is still trying to figure out what he has. His only responses have been continual hopes for the 'magic bullet' and refusal to answer basic questions - such as mine - why the refusal to consider making this a batch app?
well, finally got an answer to that one.
maybe the problem is this is a hold over from earlier designs
(maybe the fact that they are still using cobol that has been out of support for nearly 20 years is a hint)
they are doing too much with one transaction. |
|
| Back to top |
|
|
|
|
