Cobol Array dynamic declaration

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Guys could you help me with a clarification.

Is there a difference in the storage occupied between the two declarations given below.

Anuj Dhawan · Posted: Fri Aug 17, 2012 11:13 am

If the COBOL Internal Table (loosly called as arrays, whcih is not actually a COBOL term) is defined in Working-Storage with the ODO phrase, it will always be mapped to max potential size. (FILE SECTION or LINKAGE SECTION are exception).

The only way to have a "dynamic array" is to acquire storage at runtime basing your size requirement on the number of items you will have. This excellent explanation by Bill O'Boyle here might be of further interest.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Anuj , yes my bad , agreed its COBOL Internal Table

.

Let me give more insight of the issue am facing. I have this declaration in mmy CICS program , and my program is ending up issuing huge GETMAINS. After some analysis we narrowed down to the storage thats allocated at the begining of the program.

Ans seems the culprit there could be the way these COBOL Internal Tables have been declared.

dbzTHEdinosauer · Posted: Fri Aug 17, 2012 11:47 am

1. do you need these Cobol Internal Tables?

2. do you know at run time (before you populate them)
how many items you will have?

if the answers are yes/no - you are stuck.
if the answers are yes/yes - then use the method Bill has described (refer to the link that Anuj has provided).

with what are you populating these Cobol Internal Tables?

what is the frequency/activity of your cics module?

when you perform activities in cics that should be done in batch,
you always pay a price.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Thanks for all the responses.

@dbzTHEdinosauer answer is Yes/no.

The Cobol Internal Tables are used to populate the response containers of a Web service request.

Frequency is 7-8 calls / minute.

Ok coming back to my orginal question , does the two declaration make any difference or is it same ? ( I am intrested in this beacause i am being told that the second declaration would only allocate the spce that is equivalent to the Cobol Internal Tables size and not the max by default)

I actually dont know how to validate the statement.

dbzTHEdinosauer · Posted: Fri Aug 17, 2012 1:40 pm

again I ask, where is the data comming from to populate the tables?

why don't you use the container space? that memory is already allocated.

since the COBOL internal table is defined in working-storage,
the max is allocated.
look at the compile listing to validate the statement,
if you do not want to read the manuals.

now, you can continue to work with the incompetents that are giving you such garbage as info,
or you can work with us.

if you wish to work with us, answer our questions.

with what are you populating your COBOL Internal tables?
where are you getting the data?
what is the relationship of the COBOL Internal Table items
and the container space?

many of us have worked with web-apps, this is not new ground.
in order for us to help you, you need to explain what is the function of you cics service.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

with what are you populating your COBOL Internal tables? Data extracted from a DB2 table depending on a varying query( user has the flexibity to choose his WHERE clause) result from my cursor is poluated into the container which has the cobol internal table. Each row from the cursor is moved to the cobol internal table

where are you getting the data? DB2 table

what is the relationship of the COBOL Internal Table items
and the container space? COBOL Internal Table is actually in the copybook definition of my container

Bill Woodger · Posted: Fri Aug 17, 2012 2:00 pm

dbzTHEdinosauer · Posted: Fri Aug 17, 2012 2:10 pm

1. as bill has pointed out, neither of your COBOL Internal Table declarations is compilable.

2. Container space comes from the
gateway/whatever interface you are using between the web-app and the cics invocation of your program
so it should be defined in linkage.
Thus you should not have any working-storage issues.

3. you quoted your co-workers explanation,
i just pointed out that it is wrong.
if they think that way, they are incompetent.
this is a technical forum.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Anuj Dhawan · Posted: Fri Aug 17, 2012 4:18 pm

If you're intrested in, look at these threads:

ibmmainframes.com/viewtopic.php?t=47790&highlight=odo
ibmmainframes.com/viewtopic.php?t=58537&highlight=odo

OTOH, if we ignore the syntax errors then perhaps the short answer, for this,

dbzTHEdinosauer · Posted: Fri Aug 17, 2012 5:02 pm

regardless of where the declaration is,
it is always mapped at the max.

allocation:
working-storage - max
linkage depends on the length sent to the getmain service.
the length of function will return a length based on the value of the odo.

mapped and allocation are two different things.

cvishu · Active User Joined: 31 Jul 2007 Posts: 136 Location: india

Thnks guys, for all your replies (Bill O'Boyle link was informative thnks Anuj)

I tried different option, and personally my conclusion is to reduce the occurances from 9000 to a much lesser value , and go for mutiple web service call. ( In short, having some kind of recurrsive calls to get the data rather than getting everything in one go) this worked and reduced my CICS storage allocation.

This is the only solution that i have for my problem as of now. But please keep posting if you think of other ways.

Anuj Dhawan · Posted: Fri Aug 17, 2012 5:23 pm

Thanks Dick. I should have been careful ...

.

Bill O'Boyle · Posted: Fri Aug 17, 2012 8:16 pm

Preface: CICS CHANNELS/CONTAINERS were introduced with CICS/TS 3.1.

However, this initial introduction still had CHANNEL/CONTAINERS writing to EUDSA and if you have several large GETMAIN's being issued concurrently (also using EUDSA), you run the risk of SOS Above the Line.

Upon introduction of TS/3.2, a new initialization parm was added, named MEMLIMIT. The value set to this parm represents the allocation of 64-Bit storage, used internally by CICS, with a miniumum value of 3GB.

With this new parm, CHANNELS/CONTAINERS are now written internally to this 64-Bit storage, so large GETMAIN's can be replaced.

Not sure about your CICS Version/Release, but this could be an option if you're at TS/3.2 and greater.

HTH....

Bill O'Boyle · Posted: Sat Aug 18, 2012 6:41 am

I forgot to ask; What's the data-origin used to populate the dynamic table/array in the CICS program? File, program calculation/logic, another program, etc?

Bill O'Boyle · Posted: Sat Aug 18, 2012 9:48 am

Nevermind, I stand corrected....