Cobol - Occurs Depending Memory Use

Author

Occurs Depending Memory Use

Kevin Solomon

2005-05-23, 3:55 pm

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.

Michael Mattias

2005-05-23, 3:55 pm

"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

Frederico Fonseca

2005-05-23, 3:55 pm

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? 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?

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

Richard

2005-05-23, 8:55 pm

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.

Chuck Stevens

2005-05-23, 8:55 pm

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.
>

HeyBub

2005-05-23, 8:55 pm

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.

Kevin Solomon

2005-05-24, 8:55 am

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.
>

docdwarf@panix.com

2005-05-24, 8:55 am

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 is
>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

Richard

2005-05-24, 8:55 am

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

That is what disk files are for.

2005-05-24, 8:55 am

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?
>
> 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

HeyBub

2005-05-24, 3:55 pm

Kevin Solomon wrote:
> 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?

You're just kicking the can down the road.

Use disk files. Where possible, the OS will keep all the files in memory, so
you'd be letting the OS optimize your memory usage. If you ultimately suffer
a performance hit, get faster hardware.

Richard Maher

2005-05-24, 3:55 pm

Hi,

Sorry, I haven't read the entire thread but a couple of quick points anyway
:-

1) As others have stated, I also use Occurs-Depending-On (often!) for SEARCH
performance.

2) If you are using small arrays "Who really cares?".

3) I am of the opinion that if you have a Table dimensioned to take a
maximum of 100k x 5000 byte elements but you're only ever using/referencing
the first 1000 elements then your actual memory usage should reflect that
fact. That is, even though the address space has been allocated in the
executable image to cater for the maximum, that memory is never actually
paged into the processes working-set and therefore cannot consume available
physical memory or cause unnecessary paging/swapping.

4) I have always been extremely jealous of the IBM COBOL syntax (something
like?) SET ADDRESS OF ws_variable TO ws_pointer. Does it not exist? It
certainly doesn't in DEC COBOL :-( Please correct me if I'm wrong but I've
imagined it works something like this : - At run-time the program can
dynamically allocate memory to certain specifications (e.g.: size and
location (maybe it's shared memory)) then it can set the Occurs-Depending-On
size and directly map the Working-Storage item to the Dynamic Memory without
having to CALL "sub_prog" USING BY VALUE ws_address. How do you tell the
compiler not to preallocate the initial storage at compile-time? Or have I
got this all wrong?

Regards Richard Maher

"Kevin Solomon" <kjsolo@rogers.com> wrote in message
news:mK2dnUNVn_heYQzfRVn-2Q@rogers.com...
> 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.
>
>

Russell

2005-05-24, 3:55 pm

"Kevin Solomon" <kjsolo@rogers.com> wrote in
news:_sydne3EEO579g_fRVn-hQ@rogers.com:

> 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...
>
>

Assuming that the desired table size does not change within a single
transaction, put the table into linkage, manually allocate the desired
amount of memory, and be carefull not to use any verbs that might access
past the end of the table. An example would be Initialize.

You may need to use a compiler option to make it behave properly.

Also, put the variable length table in an 01 by itself. Do not put
anything AFTER the variable length portion of the table.

You may need to experiment to be certain which verbs to avoid. With
Microfocus, the Initialize verb accesses the entire table, even if you
use the ODOSLIDE compiler option. MOVE does not.

William M. Klein

2005-05-24, 8:55 pm

I know there have been lots of replies to this. A couple of points to make (and
then a "generalization".

1) IBM supports NON-Standard ODO's (Occurs Depending On) where they are either
nested or have data following them. What these do can surprise those used to
other COBOL compilers.

2) ODO's in Linkage Section and under FD's do NOT "allocate the maximum" size -
as they don't really allocate space at all. (Output Files can be funny how they
are handled, but even there you don't always create the "largest" record)

As far as working in a CICS environment with LARGE tables (whether "fixed" or
with ODO's), it is MOST common to use an EXEC CICS GETMAIN to "get" storage and
reference it in the Linkage Section. However, even there, depending upon the
actual program logic, one often (not always) gets the MAXIMUM storage size and
just "references" the current valid table entries.

For applications where these tables are "common" (shared) among multiple
occurrences of the same program or among multiple transactions, then using the
COMMAREA (or with CICS TS V3.1 a "container") or placing them in other "common"
storage and simply addressing them (again in COBOL Linkage Section) is the usual
application solution.

It should be noted, that CICS manuals have at:

http://publibz.boulder.ibm.com/cgi-...fhp3b00/1.4.1.1

explicitly states,

"Statements that produce variable-length areas, such as OCCURS DEPENDING ON,
should be used with caution within the WORKING-STORAGE SECTION."

--
Bill Klein
wmklein <at> ix.netcom.com
"Kevin Solomon" <kjsolo@rogers.com> wrote in message
news:mK2dnUNVn_heYQzfRVn-2Q@rogers.com...
> Hi Everyone:
>
> I work in a very large IBM z990 shop developing and suppporting COBOL/CICS
> applications. A colleague approached me last w

Richard

2005-05-24, 8:55 pm

> 2) ODO's ... under FD's do NOT "allocate the maximum" size -

I very much doubt that.

> as they don't really allocate space at all.

That is true for Linkage section as it merely maps onto something else,
but records areas are created and had better be 'full size'.

> (Output Files can be funny how they
> are handled, but even there you don't always create the "largest"
record)

If they don't create the 'largest' record (and I am sure that the
standard says that it will) then I can legitimately set the depending
on to maximum specified, move some data to that occurance and have it
overwrite something else (or have the data drop into some void).

It sounds like someone told you a story that blamed the compiler. Or
perhaps it was something wrong with one version 40 years ago. If it
doesn't create a record area 'full size' then it is broken.

William M. Klein

2005-05-24, 8:55 pm

The issue is that the FD provides "addressability to a file record area" it does
NOT "allocate" storage at all.

at any one time, the ONLY amount of storage that is actually "predictable" is
that which mathes where you are in your program logic. If you have (for
example)

FD MyFile
Record Varying in Size Depending On WS-leng.
01 MyRec.
05 Each-Byte occurs 1 to 9999 times depending on WS-Leng.
....
01 WS-Leng Pic 9(4).

Open Input MyFile
Read MyFile
*and this gets a 234 byte record

and you try and address
Each-Byte (235)

then results are UNPREDICTABLE and may indeed "globber" some other bit of
storage (and this may or may not be in "your programs" storage).

The same can also happen for output files.

See, for example, the following from GR(3) of the READ statement in the '02
Standard,

"The contents of any data items that lie beyond the range of the current record
are undefined at the completion of the execution of the READ statement."

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1116961190.193354.231270@g47g2000cwa.googlegroups.com...
>
> I very much doubt that.
>
>
> That is true for Linkage section as it merely maps onto something else,
> but records areas are created and had better be 'full size'.
>
> record)
>
> If they don't create the 'largest' record (and I am sure that the
> standard says that it will) then I can legitimately set the depending
> on to maximum specified, move some data to that occurance and have it
> overwrite something else (or have the data drop into some void).
>
> It sounds like someone told you a story that blamed the compiler. Or
> perhaps it was something wrong with one version 40 years ago. If it
> doesn't create a record area 'full size' then it is broken.
>

Richard

2005-05-24, 8:55 pm

> Open Input MyFile
> Read MyFile
> *and this gets a 234 byte record
> and you try and address
> Each-Byte (235)

That _may_ be true for OPEN INPUT because the only allowed operation is
to map the record in the file to the record area.

However, you specifically claimed this for Output and implicitly for
all files. With an I-O file then after a READ it had beter be exactly
as I predict, that I can access and reliably change any byte within the
occurs right up the 'to' size. Otherwise how would I rewrite a larger
record ?

> The same can also happen for output files.

Nonsense.

> See, for example, the following from GR(3) of the READ statement in the '02
> Standard,

> "The contents of any data items that lie beyond the range of the current record
> are undefined at the completion of the execution of the READ statement."

The __CONTENTS__ is undefined, that means it can be all zero or all 1s
or any random set of bits. It does not say, as you claim, that the
_memory_ is undefined or unavailable. It merely means that you must
initialise any additional area that you gain by increasing the
depending on (up to its limit of course).

Howard Brazee

2005-05-24, 8:55 pm

How many people have tables filled with high values at the end without variable
length logic?

Frederico Fonseca

2005-05-24, 8:55 pm

On Tue, 24 May 2005 20:59:54 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>How many people have tables filled with high values at the end without variable
>length logic?
~Many that I'm aware of. (dozens of different customers did that until
I convince them otherwise).

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

William M. Klein

2005-05-25, 3:55 am

Richard,
It is NOT nonsense. All of this is implementation specific. On IBM mainframes
(for example) what the "record area" points to is the "buffer area". This is
NOT part of the program's storage. Taking the original example again - and
modifying it slightly, Let's say you have:

FD OutFile
Record varying in Size depeidng on Size-1.
01 OutRec.
05 Each-Byte occurs 1 to 999 times depending on Size-2
pic x.
Open output OutFile
Move 100 to Size-1
Move 200 to Size-2
Move "X" to Each-Byte (200)

Results are UNpredictable (and once again MY clobber data).

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1116967937.156087.198120@g43g2000cwa.googlegroups.com...
>
> That _may_ be true for OPEN INPUT because the only allowed operation is
> to map the record in the file to the record area.
>
> However, you specifically claimed this for Output and implicitly for
> all files. With an I-O file then after a READ it had beter be exactly
> as I predict, that I can access and reliably change any byte within the
> occurs right up the 'to' size. Otherwise how would I rewrite a larger
> record ?
>
>
> Nonsense.
>
>
>
> The __CONTENTS__ is undefined, that means it can be all zero or all 1s
> or any random set of bits. It does not say, as you claim, that the
> _memory_ is undefined or unavailable. It merely means that you must
> initialise any additional area that you gain by increasing the
> depending on (up to its limit of course).
>

LX-i

2005-05-25, 3:55 am

Kevin Solomon wrote:
> 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?

I've never worked on an IBM mainframe, so my advice is probably worth
even less than what you're paying for... but...

If you've got the transactions in the database, why not have the
follow-on program do a "call" to get its own input? Instead of having
the database reader be in control, have the follow-on programs be in
control, and simply "call" the DB routine when they start? That way,
you're passing very small amounts around (something like, "Hey, wake up
and run"), and the programs can do their own allocation (or, if they
don't need the whole resultset sucked into memory, just run through a
cursor).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Richard

2005-05-25, 3:55 am

> It is NOT nonsense. All of this is implementation specific. On IBM mainframes
> (for example) what the "record area" points to is the "buffer area". This is
> NOT part of the program's storage. Taking the original example again - and
> modifying it slightly, Let's say you have:

> FD OutFile
> Record varying in Size depeidng on Size-1.
> 01 OutRec.
> 05 Each-Byte occurs 1 to 999 times depending on Size-2
> pic x.
> Open output OutFile
> Move 100 to Size-1
> Move 200 to Size-2
> Move "X" to Each-Byte (200)

You have deliberately abused the system by specifying conflicting
requirements on the size of the record. I may be interested in how the
compiler treats this combination of code, hopefully it notices that you
are actually lying about what sets the record size.

My reading of various descriptions indicate that the record area must
be capable of holding the largest record. Whan a record is written it
may well only write size-1 bytes or it may write size-2.

But the size of the record area will be that of the largest record
definition (999 bytes in this case). The RECORD VARYING [from x] [to y]
depending on ... will check that the definitions of each record lies
within the range x .. y. Without the x and y it will take any record
size specified.

> Results are UNpredictable (and once again MY clobber data).

You are

. I understand that back in some ancient time, some
versions of IBM compilers did, in fact, merely map the record area of
an _INPUT_ file to the block buffer. You are extrapolating urban myths.

There was also some ancient bug in a broken IBM compiler that freed the
record area on an INPUT file at end of file (rather than on close) and
this still persists as a myth.

With an I-O or OUTPUT file, however, it is necessary to be able to
access every byte of the largest record without corrupting something
else. Otherwise it would be impossible to have a working program that
could write such a record.

In the particular case of OUTPUT or I-O with MOVE .. TO ..(200), this
must always be able to work as long as size-2 is 200 (or indeed with
bound checking off) and must never overwrite some other data.

The size-1 _may_ be used by a WRITE, or it _may_ use size-2, _that_ may
even be undefined as to which it uses.

Your assertion that there is a setting of size-1 on an OUTPUT file that
causes each-byte(200) to overwrite some other data would simply
indicate that your compiler is completely munted.

Let us say that I wanted to write a 900 byte record. I MOVE 900 to
size-2 and then I can freely MOVE any data to those 900 bytes
(_WITHOUT_ overwriting other data). Now I want to WRITE so I move 900
to size-1 and WRITE.

If it doesn't do that correctly then it is not COBOL (Though I would
accept a view that the compiler should reject your code).

You are confusing undefined _content_ with undefined memory. After a
WRITE, for example, the standard states that the record is unavailable.
This does _NOT_ mean that the record _area_ is unavilable, but only
that the data within it may not as it was before.

docdwarf@panix.com

2005-05-25, 3:55 am

In article <1116980309.856744.280430@o13g2000cwo.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>
>You have deliberately abused the system by specifying conflicting
>requirements on the size of the record.

Hmmmmmm... I don't know why but that strikes me as a variant of
'Whoopsie... I ain't thunk'a that'un!'

DD

Howard Brazee

2005-05-25, 3:55 pm

On 24-May-2005, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

[color=darkred]
> ~Many that I'm aware of. (dozens of different customers did that until
> I convince them otherwise).

How did you convince them otherwise?

Frederico Fonseca

2005-05-25, 3:55 pm

On Wed, 25 May 2005 14:05:23 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 24-May-2005, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>
>
>
>How did you convince them otherwise?
It would depend on the customer and the programs he had.
In the case of tables I would teach them how to use the depending on
correctly for example.

On others I would try and setup cases where their code would either
fail or make it hard to work around the problem, and then I would
present them with ways around it without the high/low values option.

And as we don't use the standard alphabet, by defining a new one would
also mean the the value of high/values would/might not be the standard
one.

It's been a while since the last time I had to do it.

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

Michael Mattias

2005-05-25, 8:55 pm

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:gkf991t55u3mg8n1nrmkvfh8kaogk4s5l6@
4ax.com...
> On Wed, 25 May 2005 14:05:23 GMT, "Howard Brazee" <howard@brazee.net>
> wrote:
>
wrote:[color=darkred]
> It would depend on the customer and the programs he had.
> In the case of tables I would teach them how to use the depending on
> correctly for example.

Just so no one thinks Mr. Fonseca is making this up ("Who DOESN'T know
about..?") ... I once did a job at a client.. their lead COBOL
rogrammer - who had been writing their COBOL programs for nine years - not
unreasonably insisted on reviewing my source code before I could call the
job "complete."

She said it was Ok, and although she had never seen the SEARCH verb before,
my use looked right.

(Nine years COBOL programming and had never seen SEARCH? Well, it sure
taught me something: never assume anything!)

MCM

Howard Brazee

2005-05-25, 8:55 pm

On 25-May-2005, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

> And as we don't use the standard alphabet, by defining a new one would
> also mean the the value of high/values would/might not be the standard
> one.

I thought high-values was independent of the alphabet.

Frederico Fonseca

2005-05-25, 8:55 pm

On Wed, 25 May 2005 18:31:29 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 25-May-2005, Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>
>
>I thought high-values was independent of the alphabet.
Don't know about the standard, but with the COBOL my customers were
using it is as follows.

The character that has the highest ordinal position in the current
program collating sequence is associated with the figurative constant
HIGH-VALUE, except when this figurative constant is specified as a
literal in the SPECIAL-NAMES paragraph. If more than one character
has the highest position in the program collating sequence, the last
character specified is associated with the figurative constant
HIGH-VALUE.

The character that has the lowest ordinal position in the current
program collating sequence is associated with the figurative constant
LOW-VALUE, except when this figurative constant is specified as a
literal in the SPECIAL-NAMES paragraph. If more than one character
has the lowest position in the program collating sequence, the first
character specified is associated with the figurative constant
LOW-VALUE. When specified as literals in the SPECIAL-NAMES paragraph,
the figurative constants HIGH-VALUE and LOW-VALUE are associated with
those characters having the highest and lowest positions,
respectively, in the native collating sequence.

so if I define a alphabet with the following values

1,2,3,4

high-values is "4" and low-values is "1" within that alphabet.

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

Frederico Fonseca

2005-05-25, 8:55 pm

On Wed, 25 May 2005 21:10:07 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>On Wed, 25 May 2005 18:31:29 GMT, "Howard Brazee" <howard@brazee.net>
>wrote:
>
>Don't know about the standard, but with the COBOL my customers were
>using it is as follows.
Just a minor update.

COBOL Standards do mention the same as my previous post.

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

William M. Klein

2005-05-25, 8:55 pm

Yep, - and it has always (or at least as long as I have known of such) worked
this way in the Standard.

I always try to warn programmers AGAINST "assuming" that low-values is always
X'00'. In the "real world" - I have seen programs where the user defined an
alphabet with JUST the "printable" (Latin-1 with or without other Latin-x
characters). They then get "surprised" when moving low-values to someplace and
end up with something like "ALL spaces" - or "All 'A'".

--
Bill Klein
wmklein <at> ix.netcom.com
"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:h9n9911o62cq0q9n7vhujqsduc8j0bn3fg@
4ax.com...
> On Wed, 25 May 2005 21:10:07 +0100, Frederico Fonseca
> <real-email-in-msg-spam@email.com> wrote:
>
> Just a minor update.
>
> COBOL Standards do mention the same as my previous post.
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com

Howard Brazee

2005-05-25, 8:55 pm

On 25-May-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Yep, - and it has always (or at least as long as I have known of such) worked
>
> this way in the Standard.
>
> I always try to warn programmers AGAINST "assuming" that low-values is always
> X'00'. In the "real world" - I have seen programs where the user defined an
> alphabet with JUST the "printable" (Latin-1 with or without other Latin-x
> characters). They then get "surprised" when moving low-values to someplace
> and
> end up with something like "ALL spaces" - or "All 'A'".

I'm trying to figure out why it was written that way, and am not coming up with
a good reason. The whole point of having the figurative constants should be to
be independent from alphabets.

Michael Mattias

2005-05-25, 8:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:d72ga0$94b$1@peabody.colorado.edu...
>
> On 25-May-2005, Frederico Fonseca <real-email-in-msg-spam@email.com>
wrote:
>
>
> I thought high-values was independent of the alphabet.

It *is* independent of alphabet. However, it *is* dependent on the native
collating sequence and/or CODE-SET.

And if desired, you may override the values used for both the HIGH-VALUE and
LOW-VALUE figurative constants in the SPECIAL-NAMES paragraph of the
CONFIGURATION SECTION. (Of course I never did that. How dumb do I look?)

MCM

Scott Peterson

2005-05-26, 3:55 am

Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

>
>so if I define a alphabet with the following values
>
>1,2,3,4
>
>high-values is "4" and low-values is "1" within that alphabet.

OK, but how does that improve search all?

Scott Peterson

--
If you can't get the answer in
the usual manner, start at the
answer and derive the question.

116/612

Sparky Spartacus

2005-05-26, 3:55 am

HeyBub wrote:

> Kevin Solomon wrote:
>
>
>
> You're just kicking the can down the road.
>
> Use disk files. Where possible, the OS will keep all the files in memory, so
> you'd be letting the OS optimize your memory usage. If you ultimately suffer
> a performance hit, get faster hardware.

Good advice IMHO - if you're running on Big Blue's big iron you can
specify UNIT=SYSVIO (I think it's the UNIT parm, "VIO" = virtual I/O)
and the OS will place your work files on page datasets, which will
maximise your performance.

Sparky Spartacus

2005-05-26, 3:55 am

Richard wrote:

>
> I very much doubt that.
>
>
> That is true for Linkage section as it merely maps onto something else,
> but records areas are created and had better be 'full size'.

Nope, actual FD 01 areas are buffers allocated at OPEN time (which is
why you should never reference them before you OPEN your files or after
you CLOSE them).

Sparky Spartacus

2005-05-26, 3:55 am

Michael Mattias wrote:

> "Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
> news:gkf991t55u3mg8n1nrmkvfh8kaogk4s5l6@
4ax.com...
>
>
> wrote:
>
>
>
> Just so no one thinks Mr. Fonseca is making this up ("Who DOESN'T know
> about..?") ... I once did a job at a client.. their lead COBOL
> rogrammer - who had been writing their COBOL programs for nine years - not
> unreasonably insisted on reviewing my source code before I could call the
> job "complete."
>
> She said it was Ok, and although she had never seen the SEARCH verb before,
> my use looked right.
>
> (Nine years COBOL programming and had never seen SEARCH? Well, it sure
> taught me something: never assume anything!)

A lesson well learned too!

:)

Richard

2005-05-26, 8:55 am

>> but records areas are created and had better be 'full size'.

> Nope, actual FD 01 areas are buffers allocated at OPEN time

That is how they are 'created', yes. Or at least that is how they may
be created. Some compilers may create them statically (such as MF).

Frederico Fonseca

2005-05-26, 8:55 am

On Wed, 25 May 2005 18:10:30 -0700, Scott Peterson
<scottp4.removethistoreply@mindspring.com> wrote:

>Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>
>
>OK, but how does that improve search all?
>
Hum....

The use of a user-defined collating sequence or alphabet has nothing
to do with Search (ALL) performance.

Search all required that all elements of the table that are to be
searched are sorted. Normally this will be ascending order.

As such if we have a table with "PIC X(2) occurs 10" as follows

Entry(1) = "10"
Entry(2) = "20"
Entry(3) = "30"
Entry(4) = "40"
Entry(5) = spaces
Entry(6) = spaces
Entry(7) = spaces
Entry(8) = spaces
Entry(9) = spaces
Entry(10) = spaces

the search all would not work well.
So alternatives to the above are
1- Use HIGH-VALUES, or another value higher than any possible on the
other entries, but one that is not used by the application, on the
empty fields.
2- Use OCCURS DEPENDING ON and use the variables correctly

So when programmers don't know how to use the ODO they will revert to
option 1. This if dealing with a BIG table will slow down the searches
on the table.

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

Chuck Stevens

2005-05-26, 3:55 pm

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:j71b9196v3g2uhuq2tn3r7397bd5n4dib0@
4ax.com...
> As such if we have a table with "PIC X(2) occurs 10" as follows
>
> Entry(1) = "10"
> Entry(2) = "20"
> Entry(3) = "30"
> Entry(4) = "40"
> Entry(5) = spaces
> Entry(6) = spaces
> Entry(7) = spaces
> Entry(8) = spaces
> Entry(9) = spaces
> Entry(10) = spaces
>
>
> the search all would not work well.
> So alternatives to the above are
> 1- Use HIGH-VALUES, or another value higher than any possible on the
> other entries, but one that is not used by the application, on the
> empty fields.

Presuming COBOL-85, ANSI X3.23-1985 page VI-124, 6.22.4, SEARCH statement,
general rule 3: "In a format 2 SEARCH statement, the results of the SEARCH
ALL operation are predictable only when: a) The data in the table is
ordered in the same manner as described in the KEY IS phrase of the OCCURS
clause referenced by identifier-1 and b) The contents of the key(s)
referenced in the WHEN phrase are sufficient to identify a unique table
element." Putting HIGH-VALUES in the unused entries doesn't help unless
there is exactly one of them.

Note also that SEARCH and SEARCH ALL both require OCCURS ... INDEXED BY ...
..

-Chuck Stevens

Robert Jones

2005-05-26, 3:55 pm

Chuck Stevens wrote:
> "Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
> news:j71b9196v3g2uhuq2tn3r7397bd5n4dib0@
4ax.com...
>
> Presuming COBOL-85, ANSI X3.23-1985 page VI-124, 6.22.4, SEARCH statement,
> general rule 3: "In a format 2 SEARCH statement, the results of the SEARCH
> ALL operation are predictable only when: a) The data in the table is
> ordered in the same manner as described in the KEY IS phrase of the OCCURS
> clause referenced by identifier-1 and b) The contents of the key(s)
> referenced in the WHEN phrase are sufficient to identify a unique table
> element." Putting HIGH-VALUES in the unused entries doesn't help unless
> there is exactly one of them.
>
> Note also that SEARCH and SEARCH ALL both require OCCURS ... INDEXED BY ...
> .
>
> -Chuck Stevens

I think that most compilers would accept a SEARCH ALL where, provided
the key being sought were unique (i.e. not high values), the high order
elements of the table could be high values. I also think that this
behaviour would comply with the standard. However, I would agree that
it would be preferable only to search that part of the table that
contained real entries by using an ODO.

Robert

Richard Maher

2005-05-26, 3:55 pm

Hi,

HIGH-VALUES = Binary 1s

LOW-VALUES = Binary 0s

Anyone who codes otherwise should be burned at the stake! (And probably
float like a Duck)

Regards Richard Maher

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1117126995.810373.143640@g43g2000cwa.googlegroups.com...
>
>
> Chuck Stevens wrote:
statement,[color=darkred]
SEARCH[color=darkred]
OCCURS[color=darkred]
....[color=darkred]
>
> I think that most compilers would accept a SEARCH ALL where, provided
> the key being sought were unique (i.e. not high values), the high order
> elements of the table could be high values. I also think that this
> behaviour would comply with the standard. However, I would agree that
> it would be preferable only to search that part of the table that
> contained real entries by using an ODO.
>
> Robert
>

Chuck Stevens

2005-05-26, 3:55 pm

"Robert Jones" <rjones0@hotmail.com> wrote in message
news:1117126995.810373.143640@g43g2000cwa.googlegroups.com...

> I think that most compilers would accept a SEARCH ALL where, provided
> the key being sought were unique (i.e. not high values), the high order
> elements of the table could be high values. I also think that this
> behaviour would comply with the standard. ...

True enough; the results are defined for the case in which the
specifications in the WHEN clause are sufficient to identify an element
uniquely, and if HIGH-VALUES doesn't figure into the WHEN clause and all the
"valid" keys are unique, then SEARCH ALL should work. Duplicate items
according to the INDEXED BY clause should cause problems for SEARCH ALL only
if you're looking for one of them; what isn't defined is which one you get,
whether you find one of them at all, or even whether what you end up with is
something like rutabagas or novembers.

-Chuck Stevens

Howard Brazee

2005-05-26, 3:55 pm

On 26-May-2005, "Robert Jones" <rjones0@hotmail.com> wrote:

> I think that most compilers would accept a SEARCH ALL where, provided
> the key being sought were unique (i.e. not high values), the high order
> elements of the table could be high values. I also think that this
> behaviour would comply with the standard. However, I would agree that
> it would be preferable only to search that part of the table that
> contained real entries by using an ODO.

That might save a search step. But with with some overhead (we now have to
track table size). I tend* to use variable length tables when I write new
programs, but have not "corrected" existing code, nor made it a priority to push
that technique. The advantage is too minimal in an environment where I can
trust my HIGH-VALUES to be larger than any key.

*tend = I don't even "correct" the code (for this purpose) when I'm doing
extensive cutting and pasting from existing code.

Chuck Stevens

2005-05-26, 3:55 pm

"Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message
news:d74vv4$g53$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
> Hi,
>
> HIGH-VALUES = Binary 1s
>
> LOW-VALUES = Binary 0s
>
> Anyone who codes otherwise should be burned at the stake! (And probably
> float like a Duck)
>
> Regards Richard Maher
>

Sorry, Richard, but that's not the way the COBOL standard defines
HIGH-VALUES and LOW-VALUES.

There is no requirement that the "program collating sequence" contains a
particular number of bits per character, nor is there a requirement that all
bit patterns possible in that scheme are represented in the collating
sequence. See ANSI X3.23-1985 page IV-11, 4.2.2.2.3, Figurative Constant
Values rules 3 and 4, and ibid. page VI-16, 4.5.4, The SPECIAL-NAMES
Paragraph, general rules 5 and 6.

It's commonly true that the program collating sequence runs from 1 through
256, but there's no requirement that it start at 1 and end at a larger power
of two.

-Chuck Stevens

Sparky Spartacus

2005-05-26, 3:55 pm

Richard wrote:
>
>
>
>
> That is how they are 'created', yes. Or at least that is how they may
> be created. Some compilers may create them statically (such as MF).

I thought the context was IBM Mainframes, specifically the MVC/zOS level?

Richard

2005-05-26, 8:55 pm

> I thought the context was IBM Mainframes, specifically the MVC/zOS level?

Certainly IBM Mainframes do _create_ the record areas when the file is
OPENed and release it on CLOSE, but others do that too, such as
Fujitsu, and some do not, such as MF.

The distiction that I made was between FD areas and Linkage which Bill
had lumped together.

You seemed to want to show there was difference other than semantic
between 'create' and 'allocate'. Are you now saying that there is such
a distinction on MVC/zOS ?

William M. Klein

2005-05-26, 8:55 pm

The distinction that I was *trying* to make in my original post was between
Working-Storage (and Local-Storage) versus File and Linkage. In the latter two,
the program *MAY* (but doesn't have to) get "addressability" to storage that
"belongs" to someone (operating system, other program, file system, whatever) -
while with the former two, the program MUST "allocate" the storage itself
(whether in the object code or via dynamic allocation at run-time).

OBVIOUSLY (I think) there are differences between Linkage Section and File
Section as to where the "storage" is. However, related to the ORIGINAL post -
when it comes to ODO's (Occurs Depending On) the application program MAY
(depending upon implementation) ONLY get addressability to the maximum storage
needed at the beginning of the program and only get additional addressability
when program logic requires it. This is NOT true for Working or Local-Storage
(or certainly not AS true).

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1117134253.647799.300080@f14g2000cwb.googlegroups.com...
>
> Certainly IBM Mainframes do _create_ the record areas when the file is
> OPENed and release it on CLOSE, but others do that too, such as
> Fujitsu, and some do not, such as MF.
>
> The distiction that I made was between FD areas and Linkage which Bill
> had lumped together.
>
> You seemed to want to show there was difference other than semantic
> between 'create' and 'allocate'. Are you now saying that there is such
> a distinction on MVC/zOS ?
>

Richard

2005-05-26, 8:55 pm

> MAY
> (depending upon implementation) ONLY get addressability to the maximum storage
> needed at the beginning of the program and only get additional addressability
> when program logic requires it.

Your example stated that for an output file after an OPEN the record
area may at one time be, say, 100 bytes and at another time it may be
999 bytes. Further you said that the difference of 899 may address
some other storage area (and thus overwrite) or be 'void'.

I simply do not believe that the standard can be interpreted that way,
especially when it states that the record area will be the largest of
any record definition within it. For example in the READ statement:
"this is equivalent to an implicit redefinition of the area". REDEFINES
allows the _same_ computer storage to be described.

The RECORD VARYING may in itself set a maximum but this is only a
constraint on the definitions of the FD records. For example:

RECORD VARYING FROM 20 TO 60 ...
01 ... PIC X(80).

should give a _compiler_ error, and not leave 20 bytes hanging in the
void.

Your example without the FROM . TO will not error and will explicitly
create a record area of the largest size. The compiler will neither
know nor care what the 'depending on' value is at compile time.

Certainly you could get an abend or corruption (or bound check) if you
set size-2 greater than 999 or used a subscript more than 999, but you
stated that this would occur on an output file when the subscript was
within the maximum size defined for the record.

You may have a system that maps reads on input files to the block
buffer in which case the record area should be treated as if it were
'read only', but output and i-o files are required to allow a record of
the maximum size defined (in an 01) to be filled with data and written.

> and only get additional addressability when program logic requires it.

Oh yeah ? give an example of how _that_ magic works.

MOVE 'X' TO record-char(somenumber)

OK, my logic may now require 'additional addressability' (depending
what the value of somenumber is).

You are extrapolating an urban myth from a munted compiler decades ago
by misinterpreting what "The _content_ .. is undefined" and "the record
is unavailable" means.

> OBVIOUSLY (I think) there are differences between Linkage Section and File
> Section as to where the "storage" is.

No. There is also the difference that a CALLed program has no means
other than what the CALLer tells it explicitly as to the size of the
passed data area. (actually there is ANY in more recent
implementations). You cannot rely on the defined size of the area in
the LINKAGE section to have any relationship to the size of the area
actually passed.

FD records implicitly redefine each other and the area is the size of
the largest definition. That is what the standard says.

Richard

2005-05-26, 8:55 pm

Howard Brazee

2005-05-27, 3:55 am

How many people have tables filled with high values at the end without variable
length logic?

Scott Peterson

2005-05-27, 3:55 am

"Robert Jones" <rjones0@hotmail.com> wrote:

>I think that most compilers would accept a SEARCH ALL where, provided
>the key being sought were unique (i.e. not high values), the high order
>elements of the table could be high values. I also think that this
>behaviour would comply with the standard. However, I would agree that
>it would be preferable only to search that part of the table that
>contained real entries by using an ODO.

I don't think the table entries need to be unique as long as they are
in the correct sequence. This certainly is not validated when the
table is loaded and there's certainly nothing in a straight binary
search algorithm that would preclude this. But the search will be
unpredictable as you cannot know which non-unique entry will returned
when you use SEARCH ALL. As long as that is acceptable. Go for it.

Scott Peterson

--
f u cn rd ths, yur ethr a unx
sysdmn or a tnager nto SMS.

318/612

Scott Peterson

2005-05-27, 3:55 am

Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

>
>So when programmers don't know how to use the ODO they will revert to
>option 1. This if dealing with a BIG table will slow down the searches
>on the table.
>

I understand. But even so, on a 100 element table and assuming random
searches the average search using SEARCH ALL will take 6 probes. Up
that to a million entries and that number will only go up to 20.

This has always been one of those cases where it's very difficult to
really improve things very much if it's done right in the first
place...and the searches are reasonably randomized.

The main place where I've been able to improve this has been cases
where the hits in the table were not random. Then there's quite a bit
you can do.

Scott Peterson

--
You know how dumb the average
person is? Well, by definition,
half of 'em are dumber

220/612

Sparky Spartacus

2005-05-27, 3:55 am

Richard wrote:

>
> Certainly IBM Mainframes do _create_ the record areas when the file is
> OPENed and release it on CLOSE, but others do that too, such as
> Fujitsu, and some do not, such as MF.
>
> The distiction that I made was between FD areas and Linkage which Bill
> had lumped together.
>
> You seemed to want to show there was difference other than semantic
> between 'create' and 'allocate'. Are you now saying that there is such
> a distinction on MVC/zOS ?

<MVC is, of course, MVS>

Re: create v. allocate, I was trying to use the correct terminology (as
I remember it of course). MVS, et al., doesn't go thru a "create" phase,
but it does go thru an "allocation" phase. Just trying to be tidy with
my language.

In real life, the 01's for the FD's could be placed in the Linkage
Section because there's no addressability to anything until the FD's are
OPENed. The difference, of course, is that it's up to the programmer to
provide addressability to other items in the Linkage Section and it's
accomplished differently from OPENing files.

Chuck Stevens

2005-05-27, 3:55 pm

"Scott Peterson" <scottp4.removethistoreply@mindspring.com> wrote in message
news:119daflcv5nqt7d@news.supernews.com...

> I understand. But even so, on a 100 element table and assuming random
> searches the average search using SEARCH ALL will take 6 probes. Up
> that to a million entries and that number will only go up to 20.
>
> This has always been one of those cases where it's very difficult to
> really improve things very much if it's done right in the first
> place...and the searches are reasonably randomized.
>
> The main place where I've been able to improve this has been cases
> where the hits in the table were not random. Then there's quite a bit
> you can do.

Remember that the standard doesn't *specify* a binary -- or even a
non-serial -- search for SEARCH ALL, it merely *allows* it. There is no
guarantee that a SEARCH ALL will require any less execution-time resources
than the corresponding SEARCH, though most (not all) implementations make it
so.

-Chuck Stevens

Howard Brazee

2005-05-27, 3:55 pm

On 27-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Remember that the standard doesn't *specify* a binary -- or even a
> non-serial -- search for SEARCH ALL, it merely *allows* it. There is no
> guarantee that a SEARCH ALL will require any less execution-time resources
> than the corresponding SEARCH, though most (not all) implementations make it
> so.

I don't even code a SEARCH ALL for tiny tables. Sometimes a serial search is
quicker than a binary search even if it makes more comparisons.

Scott Peterson

2005-05-28, 3:55 am

"Chuck Stevens" <charles.stevens@unisys.com> wrote:

>Remember that the standard doesn't *specify* a binary -- or even a
>non-serial -- search for SEARCH ALL, it merely *allows* it.

I thought about that qualification after I wrote it and you're right.
SEARCH ALL is just a keyed search and how it's implemented is not
something a COBOL programmer should have to care about very much other
than it's fast. But the IBM implementations I've used have all been
binary searches, as far as I know.

>There is no
>guarantee that a SEARCH ALL will require any less execution-time resources
>than the corresponding SEARCH, though most (not all) implementations make it
>so.

The whole point of search all is that it should provide a faster
search from an execution point of view. Not that it's less resource
intensive.

Scott Peterson

--
Psychiatrists say that 1 of 4 people
are mentally ill. Check 3 friends.
If they're OK, you're it.

199/612

Scott Peterson

2005-05-28, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote:

>I don't even code a SEARCH ALL for tiny tables. Sometimes a serial search is
>quicker than a binary search even if it makes more comparisons.

It's not a matter of size. Speed will be the result of how many
probes does it take to get a hit. For example. I worked on a couple
of programs with very large tables with very non-random distribution
of data.

By manipulating the data to put the most probable hits in the first
few entries, a sequential SEARCH outperformed a SEARCH ALL for that
particular program.

Scott Peterson

--
A paperless office has about as much
chance as a paperless bathroom.

303/612

Frederico Fonseca

2005-05-29, 3:55 am

Richard

2005-05-29, 3:55 am

Scott Peterson

2005-05-29, 3:55 pm

Russell

2005-05-30, 3:55 am

William M. Klein

2005-05-30, 3:55 am

Chuck Stevens

2005-05-30, 3:55 am

Richard

2005-05-30, 3:55 am

Scott Peterson

2005-05-30, 3:55 pm

Sparky Spartacus

2005-05-30, 3:55 pm

Scott Peterson

2005-05-30, 3:55 pm

Chuck Stevens

2005-05-30, 3:55 pm

William M. Klein

2005-05-31, 3:55 am

Howard Brazee

2005-05-31, 3:55 pm

On 27-May-2005, Scott Peterson <scottp4.removethistoreply@mindspring.com> wrote:

>
> It's not a matter of size. Speed will be the result of how many
> probes does it take to get a hit. For example. I worked on a couple
> of programs with very large tables with very non-random distribution
> of data.
>
> By manipulating the data to put the most probable hits in the first
> few entries, a sequential SEARCH outperformed a SEARCH ALL for that
> particular program.

You are absolutely right. Know your data.

I like the way interpreted Basic pr