Occurs Depending Memory Use

Hi Everyone:

I work in a very large IBM z990 shop developing and suppporting COBOL/CICS
applications.  A colleague approached me last w with an interesting
question on memory allocation and memory use in employing an OCCURS
DEPENDING ON clause versus an OCCURS (integer) TIMES clause.

If I define a table with a static clause, I know that memory allocation and
use will be 2,000 bytes.  As follows...

01 WS-FILLER.
05 BASE-TABLE-1 OCCURS 100 TIMES.
10 BT-1-FIRST        PIC X(10).
10 BT-1-SECOND       PIC X(10).

If I define a second table with an OCCURS DEPENDING ON clause I had be
taught (and never before questioned) that memory allocation was dynamic.
The memory used would be only that which corresponds to the size of one
occurrence times the value of the depending on variable.  In the example
below, at the start of execution I would expect the size of the table to be
20 bytes and only the maximum size to be static at 2,000 bytes.

05 BASE-TABLE-2 OCCURS 1 TO 100 TIMES DEPENDING ON MY-VAR.
10 BT-2-FIRST        PIC X(10).
10 BT-2-SECOND       PIC X(10).

05 MY-VAR               PIC 9(4) COMP VALUE +1.

Yet, when I look at the compiled SAR listing of a program employing both
clauses I see that the memory map of both tables allocates 2,000 bytes.
Furthermore, when I step through the program I observe that the allocation
of BASE-TABLE-2 stays at 2,000 bytes regardless of the value of MY-VAR.
Additionally, when I put a CICS trace on the execution of a program using
BASE-TABLE-1 and then replace BASE-TABLE-1 by BASE-TABLE-2, keeping the
value of MY-VAR constant at 5, the total memory use reported in the trace is
identical for both program versions.

So, how much memory is actually used by an OCCURS DEPENDING ON clause?  What
exactly is the difference between using OCCURS and OCCURS DEPENDING ON?  If
there's no real savings in memory, then what's the point?

Any help provided will be greatly appreciated.  Thanks.

"Kevin Solomon" <kjsolo@rogers.com> wrote in message
news:mK2dnUNVn_heYQzfRVn-2Q@rogers.com...
> So, how much memory is actually used by an OCCURS DEPENDING ON clause?
What
> exactly is the difference between using OCCURS and OCCURS DEPENDING ON?
If
> there's no real savings in memory, then what's the point?

The point is the SEARCH and  SEARCH ALL functions will only search the first
DEPENDING ON table entries...

MCM

On Mon, 23 May 2005 11:54:08 -0400, "Kevin Solomon"
<kjsolo@rogers.com> wrote:

>Hi Everyone:
>
>I work in a very large IBM z990 shop developing and suppporting COBOL/CICS
>applications.  A colleague approached me last w with an interesting
>question on memory allocation and memory use in employing an OCCURS
>DEPENDING ON clause versus an OCCURS (integer) TIMES clause.
Memory is allocated for the FULL occurs as if it had not been defined.

>So, how much memory is actually used by an OCCURS DEPENDING ON clause?  Wha
t
>exactly is the difference between using OCCURS and OCCURS DEPENDING ON?  If
>there's no real savings in memory, then what's the point?

As Michael mentioned it is used on the Search and Search all verbs.

If not used and if you have a table with 10000 occurs, then all of
them are searched on a sequential search, even if you have only 10
entries. Same for search all which will (normally) do a binary search.
The less occurs they have to search the faster it will be.




Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Kevin Solomon wrote:
> Hi Everyone:

> If I define a second table with an OCCURS DEPENDING ON clause I had
be
> taught (and never before questioned) that memory allocation was
dynamic.

The overhead of reallocating the memory every time the 'depending on'
changed would be a complete waste.  Typically a table may be built by
adding one item at a time and incrementing the depending on before
loading the data. This would mean that each increment would create a
new block of memory and then copy over the data to the new area and
release the old. Or how did you think dynamic memory worked ?

> The memory used would be only that which corresponds to the size of
one
> occurrence times the value of the depending on variable.

And what would be the point ? of actually reducing the memory, would
this allow some other program to use it ?  If it did the table could
not grow back in the same place.

It acts _as_if_ it is the size specified by the depending on, but does
not allow other programs or other data areas to use the memory up to
the maximum specified.

> If there's no real savings in memory, then what's the point?

It acts _as_if_ the depending on is the actual size. If you write a
record it writes that size, not the whole area. SEARCH and SORT use
that size.  If you MOVE the record, again only that size (saving CPU
cycles). BOUND chacks _may_ be done based on the depending on and not
the maximum size.

I would ask: what would be the point in reallocating a new memory area
and copying every time the depending on changes ? - because you would
have to to change the total memory usage.

Note that proposals to include the ability to declare "true"
dynamic-capacity tables as well as elementary items whose size can be varied
at execution time have been approved for inclusion in the working draft for
the COBOL standard that is planned for publication in 2008.

-Chuck Stevens

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1116875010.516177.103750@o13g2000cwo.googlegroups.com...
>
> Kevin Solomon wrote: 
> 
> be 
> dynamic.
>
> The overhead of reallocating the memory every time the 'depending on'
> changed would be a complete waste.  Typically a table may be built by
> adding one item at a time and incrementing the depending on before
> loading the data. This would mean that each increment would create a
> new block of memory and then copy over the data to the new area and
> release the old. Or how did you think dynamic memory worked ?
> 
> one 
>
> And what would be the point ? of actually reducing the memory, would
> this allow some other program to use it ?  If it did the table could
> not grow back in the same place.
>
> It acts _as_if_ it is the size specified by the depending on, but does
> not allow other programs or other data areas to use the memory up to
> the maximum specified.
> 
>
> It acts _as_if_ the depending on is the actual size. If you write a
> record it writes that size, not the whole area. SEARCH and SORT use
> that size.  If you MOVE the record, again only that size (saving CPU
> cycles). BOUND chacks _may_ be done based on the depending on and not
> the maximum size.
>
> I would ask: what would be the point in reallocating a new memory area
> and copying every time the depending on changes ? - because you would
> have to to change the total memory usage.
>

Kevin Solomon wrote:
> Hi Everyone:
>
> I work in a very large IBM z990 shop developing and suppporting
> COBOL/CICS applications.  A colleague approached me last w with an
> interesting question on memory allocation and memory use in employing
> an OCCURS DEPENDING ON clause versus an OCCURS (integer) TIMES clause.
>
> If I define a table with a static clause, I know that memory
> allocation and use will be 2,000 bytes.  As follows...
>
> 01 WS-FILLER.
>   05 BASE-TABLE-1 OCCURS 100 TIMES.
>      10 BT-1-FIRST        PIC X(10).
>      10 BT-1-SECOND       PIC X(10).
>
> If I define a second table with an OCCURS DEPENDING ON clause I had be
> taught (and never before questioned) that memory allocation was
> dynamic. The memory used would be only that which corresponds to the
> size of one occurrence times the value of the depending on variable.
> In the example below, at the start of execution I would expect the
> size of the table to be 20 bytes and only the maximum size to be
> static at 2,000 bytes.
>
>   05 BASE-TABLE-2 OCCURS 1 TO 100 TIMES DEPENDING ON MY-VAR.
>      10 BT-2-FIRST        PIC X(10).
>      10 BT-2-SECOND       PIC X(10).
>
>   05 MY-VAR               PIC 9(4) COMP VALUE +1.
>
> Yet, when I look at the compiled SAR listing of a program employing
> both clauses I see that the memory map of both tables allocates 2,000
> bytes. Furthermore, when I step through the program I observe that
> the allocation of BASE-TABLE-2 stays at 2,000 bytes regardless of the
> value of MY-VAR. Additionally, when I put a CICS trace on the
> execution of a program using BASE-TABLE-1 and then replace
> BASE-TABLE-1 by BASE-TABLE-2, keeping the value of MY-VAR constant at
> 5, the total memory use reported in the trace is identical for both
> program versions.
>
> So, how much memory is actually used by an OCCURS DEPENDING ON
> clause?  What exactly is the difference between using OCCURS and
> OCCURS DEPENDING ON?  If there's no real savings in memory, then
> what's the point?

How'd you get the idea that ODO was a space-saver?

Usually (and I don't know of a case to the contrary) the compiler allocates
the maximum memory for which the table is defined. Others have mentioned
this depiction as a short-cut for SEARCH. It can also be used in writing
records as in:

WRITE MYFILE FROM BASE-TABLE

where the actual size of BASE-TABLE varies. I'm sure other clever
programmers can come up with additional uses.

Thanks to everyone for your replies.

If I understand what Richard's saying, the only real savings of using an
OCCURS DEPENDING ON clause is in overall performance and not in the amount
of memory allocated.  Of course, this means that I do not have a solution to
the actual problem we were trying to solve with this construct.

The problem is simply that we have a program that for the next processing
year will require seven or eight tables of between 1 and 10,000 occurrences
and we're endevouring to find a way to use only the amount of memory that is
actually necessary for each iteration.  As I stated in my original post, the
program executes online in CICS.  (If the program was executing in batch,
we'd not have a need to optimize memory.)  There is a potential for several
hundred concurrent users of the program.  If one iteration of the program
requires 4MB-6MB of memory and there are several hundred concurrent users
and several thousands of other programs competing for resources, you can see
why we'd rather not take 4MB of memory for each instance of the program when
it is only the maximum that would be required.

The number of occurences that are required for each iteration is variable
upon a count of transactions returned from a DB call.  Does anyone have any
ideas on how memory use might be optimized?

Thanks.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1116875010.516177.103750@o13g2000cwo.googlegroups.com...
>
> Kevin Solomon wrote: 
> 
> be 
> dynamic.
>
> The overhead of reallocating the memory every time the 'depending on'
> changed would be a complete waste.  Typically a table may be built by
> adding one item at a time and incrementing the depending on before
> loading the data. This would mean that each increment would create a
> new block of memory and then copy over the data to the new area and
> release the old. Or how did you think dynamic memory worked ?
> 
> one 
>
> And what would be the point ? of actually reducing the memory, would
> this allow some other program to use it ?  If it did the table could
> not grow back in the same place.
>
> It acts _as_if_ it is the size specified by the depending on, but does
> not allow other programs or other data areas to use the memory up to
> the maximum specified.
> 
>
> It acts _as_if_ the depending on is the actual size. If you write a
> record it writes that size, not the whole area. SEARCH and SORT use
> that size.  If you MOVE the record, again only that size (saving CPU
> cycles). BOUND chacks _may_ be done based on the depending on and not
> the maximum size.
>
> I would ask: what would be the point in reallocating a new memory area
> and copying every time the depending on changes ? - because you would
> have to to change the total memory usage.
>

In article <_sydne3EEO579g_fRVn-hQ@rogers.com>,
Kevin Solomon <kjsolo@rogers.com> wrote:

[snip]

>The problem is simply that we have a program that for the next processing
>year will require seven or eight tables of between 1 and 10,000 occurrences
>and we're endevouring to find a way to use only the amount of memory that i
s
>actually necessary for each iteration.

Hmmmmm... sounds like a system that's outgrown its original specs and has
been patched and prodded and 'all ya gotta do is'd' until nothing more
along those lines will work.

[snip]

>The number of occurences that are required for each iteration is variable
>upon a count of transactions returned from a DB call.  Does anyone have any
>ideas on how memory use might be optimized?

Sure... and I'll give it to you for free, too.  It is a single word of
eight letters, it starts with 're', ends with 'design' and has been
defined as 'to revise in appearance, function or content'.

Need more than that?  Not a problem, have someone who has budgetary
authority to sign my timesheets get in touch with me.

>
>Thanks.

No prob... worth at least double what I've asked you to pay for it.

DD

> will require seven or eight tables of between 1 and 10,000
occurrences

That is what disk files are for.

Kevin Solomon wrote:
> Hi Everyone:
>
> I work in a very large IBM z990 shop developing and suppporting COBOL/CICS
> applications.  A colleague approached me last w with an interesting
> question on memory allocation and memory use in employing an OCCURS
> DEPENDING ON clause versus an OCCURS (integer) TIMES clause.
>
> If I define a table with a static clause, I know that memory allocation an
d
> use will be 2,000 bytes.  As follows...
>
> 01 WS-FILLER.
>    05 BASE-TABLE-1 OCCURS 100 TIMES.
>       10 BT-1-FIRST        PIC X(10).
>       10 BT-1-SECOND       PIC X(10).
>
> If I define a second table with an OCCURS DEPENDING ON clause I had be
> taught (and never before questioned) that memory allocation was dynamic.
> The memory used would be only that which corresponds to the size of one
> occurrence times the value of the depending on variable.  In the example
> below, at the start of execution I would expect the size of the table to b
e
> 20 bytes and only the maximum size to be static at 2,000 bytes.
>
>    05 BASE-TABLE-2 OCCURS 1 TO 100 TIMES DEPENDING ON MY-VAR.
>       10 BT-2-FIRST        PIC X(10).
>       10 BT-2-SECOND       PIC X(10).
>
>    05 MY-VAR               PIC 9(4) COMP VALUE +1.
>
> Yet, when I look at the compiled SAR listing of a program employing both
> clauses I see that the memory map of both tables allocates 2,000 bytes.
> Furthermore, when I step through the program I observe that the allocation
> of BASE-TABLE-2 stays at 2,000 bytes regardless of the value of MY-VAR.
> Additionally, when I put a CICS trace on the execution of a program using
> BASE-TABLE-1 and then replace BASE-TABLE-1 by BASE-TABLE-2, keeping the
> value of MY-VAR constant at 5, the total memory use reported in the trace 
is
> identical for both program versions.
>
> So, how much memory is actually used by an OCCURS DEPENDING ON clause?  Wh
at
> exactly is the difference between using OCCURS and OCCURS DEPENDING ON?  I
f
> there's no real savings in memory, then what's the point?
>
> Any help provided will be greatly appreciated.  Thanks.
>
>
Have you considered using the LE Callable Services to do dynamic storage
allocation.  There are lots of considerations for how you do this so
you'll have to do your homework and read the LE Programming Guide and
Programming Reference so you can select the functions you want to use.

If you design your application carefully, you can probably allocate only
the storage that you actually need.

Carl