|
View previous topic :: View next topic
|
| Author |
Message |
smaru
New User
Joined: 22 Oct 2008
Posts: 49
Location: India
|
|
|
|
Many of my programs are facing overflow issues in table i.e. exceeding the specified array limit. Is there a way to identify the number of trasactions loaded in an array in a particular execution of the program from the log. So that I can monitor the size and increase it, before they actually fail.
I can change my programs to display the index value and monitor the growth but I would want to check if the same can be captured by any other options. |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
What are you calling "the log"?
| Quote: |
| I can change my programs to display the index value and monitor the growth but I would want to check if the same can be captured by any other options. |
Sure, implement code to keep track of usage and at the end of each run put this info in a database table or vsam file. . . |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Are you populating the array from a Flat-File or a VSAM-File? I've erroneously suggested in the past that a REXX LISTDSI command would return the number of records on a Flat-File, but that's incorrect. 
As far as VSAM, you can obtain the number of records associated with a given file via a SHOWCB Macro in a small Assembler sub-program, called from COBOL.
If you do have a Flat-File, you can REPRO it into a temporary (predefined) EDS file and then use the sub-program which invokes the SHOWCB to obtain the number of records.
Once you know the number of records and LRECL of each, you could acquire the correct amount of dynamic-storage, via the LE Callable Service routine "CEEGTST".
With that, your array definition can be placed in LINKAGE, with a true OCCURS DEPENDING ON maximum.
Using this approach, array-spillover will become almost non-existent.
If you can wait until the program (job/step) has completed, the dynamic-storage will be implicitly freed by the operating system.
Otherwise, you can explicitly free this storage via the LE Callable Service routine "CEEFRST".
Bill |
|
| Back to top |
|
|
smaru
New User
Joined: 22 Oct 2008
Posts: 49
Location: India
|
|
|
|
Bill,
Thanks a lot for the reply. Although I'm not familier with the options you specified, I will learn, try to implement and post my queries. |
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
| This sounds like an array is the wrong data structure to be using. A linked list or tree sounds like a better option because you can grow them dynamically. You could also dynamically reallocate the array (I assume - I don't know COBOL) but that would mean that at some point you have 2 copies of the data in storage. More programming, but the situation sounds like it needs it. What happens next month when this month's numbers prove to be too small? |
|
| Back to top |
|
|
|
|
