View previous topic :: View next topic
|
Author |
Message |
esduman61
New User
Joined: 08 Mar 2016 Posts: 2 Location: türkiye
|
|
|
|
There is a storage violation problem in our mainframe about one transaction which is consuming large amount of storage when it is running.
In that trx, many sub-programs are being called. We need to find amount of the storage usage in terms of the sub-programs being called in that trx (i.e. the root pgm of the trx is A , A is calling B , B is calling C etc. We need the storage usage of A , B and C respectively.
Could you please help us how can we extract these information ?
Thanks in advance
-Erkan |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Is it a CICS system? Have you asked your technical support what is available? Have you looked at the module sizes? Have you looked at the code? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Your CICS System Support group is where you should go. Do you have IBM's Fault Analyzer? When a SYSDUMP occurs, it will give you a total amount of storage used by a given task, regardless if the task is the culprit which caused the SV or not. Your programs should be allocating 31-Bit storage from the User/EDSA. Are your experiencing SOS conditions?
There are many ways to debug something like this so again, check with your Support group and/or your CICS System Programmer(s).
HTH.... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
There is a storage violation problem in our mainframe about one transaction which is consuming large amount of storage when it is running.
|
there is no relation whatsoever between a storage violation and the amount of storage used
( as long as the storage is accessed properly )
remember ...
most often/almost always, in CICS the task abending because of the storage violation is not the one who caused it |
|
Back to top |
|
|
esduman61
New User
Joined: 08 Mar 2016 Posts: 2 Location: türkiye
|
|
|
|
Thanks for all the replies.
Special thanks to "enrico-sorichetti" for his following comment : "most often/almost always, in CICS the task abending because of the storage violation is not the one who caused it". I strongly agree with this but unfortunately the owner of the abending task is always responsiple for replying or solving the problem.
We are using CICS and we have CICS support team. But we can't find any way to extract the storage usage in terms of the sub-programs of a task. We can see the total amount of usage by using "OMEGAVIEW " application. But as i indicate, we need storage usage of all of the sub-programs running in the task respectively. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3051 Location: NYC,USA
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
But as i indicate, we need storage usage of all of the sub-programs running in the task respectively. |
No, you think you need to know this and you're probably not going to be able to get it. Depending on how the subprograms are invoked, it may not even be possible to get this data. A storage violation has absolutely NOTHING to do with subprogram storage usage and everything to do with storage overlay(s) -- that is, storage taking more bytes than it is supposed to. I've seen storage violations caused by programs calling subprograms with mis-matched parameter / argument lists, and table overflows, and copy book mis-matches, and communications buffer overflows.
As long as you are looking at the storage used by the subprograms, you are not looking at the trace and dump and figuring out where the REAL issue is. To find and fix a storage violation, you look at the trace and the dump to see what storage got overlaid and then -- if you are lucky -- you track it back to a particular program. |
|
Back to top |
|
|
|