OCCURS DEPENDING ON

This is a Mainframe COBOL forum - you can post your queries on Mainframe COBOL, VS COBOL II, COBOL/370 , Enterprise COBOL

Moderators: dbzTHEdinosauer, Moderator Group

Post Reply
jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

OCCURS DEPENDING ON

Post by jeroc » Mon Dec 17, 2012 2:35 pm

Hello,

Is there any recommendation or best practice to respect in using OCCURS DEPENDING ON clause? I mean, what are advantages, pitfalls, or potential troubles?

Regards,

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Mon Dec 17, 2012 2:37 pm

Using it for what?

jeroc
Member
Posts: 17
Joined: Mon Dec 03, 2007 8:14 pm

Post by jeroc » Mon Dec 17, 2012 2:59 pm

In file records and in working-storage data structures.

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Mon Dec 17, 2012 3:27 pm

I asked for what?, not where.

If you are only using it in support of variable-length records, make sure, if at all possible, that the ODO part of the record is the LAST part of the record. This will avoid most of the "problems" people tend to have with ODO.

Hold the ODO value on the record.

If you have had specific problems, set them out for us. I don't think anyone is going to write a treatise on ODO for you. Do some research, let us know if there is anything you don't understand.

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Sun Dec 30, 2012 8:13 am

Jeroc,

one of the primary advantages of using the ODO clause on an array in working storage is that it does NOT have to be initialized.

hint ---> to initialize the array move ZERO to the ODO variable.

from a resource usage perspective this is much more efficient, especially when initializing the array many times (especially true in an online transaction).

Chuck H.
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Sun Dec 30, 2012 3:00 pm

And how do you feel that that works? Can you give an example? I've been adding up values per order-type for each new customer.

What is the difference between your method and MOVE ZERO TO subscript?

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Tue Jan 01, 2013 12:27 am

William,

moving zero to the subscript works exactly the same way with the exception that if you use a SEARCH or SEARCH ALL verb, then the array must be initialized properly in order for those verbs to work correctly with a fixed length array.

using an ODO variable length array eliminates the need to initial the array in order for the SEARCH and SEARCH ALL verbs to work correctly.

on arrays its always best to try to avoid initializing them if it can be avoided. as that is extra overhead that is not needed.

ps.. i work for a company which has huge data sources. we have some arrays in cics regions which are loaded into shared memory and are accessed 100's of billions of times per day. performance of the access to those arrays is critical.

we hand coded our binary search logic so that we could emulate a VSAM start verb. in the process we found that our hand coded binary search was quite a bit more efficient than a SEARCH ALL verb (we only single group level variable in the search logic).
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

DikDude
Moderator
Posts: 1001
Joined: Fri Jul 22, 2011 8:39 am
Location: usa

Post by DikDude » Tue Jan 01, 2013 1:24 am

in the process we found that our hand coded binary search was quite a bit more efficient than a SEARCH ALL verb
This has been my experience as well - custom written "things" tend to outperform generic "things". Also, when some of my clients faced similar opportunities, a concession was made that these performance critical "things" could be implemented in assembler.

Since this was done, the compilers, the cpus, the dasd and pretty much everything else has evolved, so i'm not sure just how true this might be today.
Have a good one

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Tue Jan 01, 2013 5:03 am

Chuck, without mentioning SEARCH ALL in your first post, "intialising an array" looks like a table of values. I wondered what magic you were suggesting.

SEARCH need not benefit from ODO. SEARCH works correctly with a fixed-length table.

For SEARCH ALL it is certainly sound advice to use ODO for the table, although, the "initialise to high key" method works correctly with no ODO (does consume more CPU, mostly). Can't say I've come across a table with SEARCH ALL which has to be initialised many times during the online, but, if it's the requirement...

Is that sample of the hand-coded binary search that you posted the one you are using today? I'd want to change it if it is used 100s of billions of times a day. Even if it were one bbillion, or a hundred million. Or a million.

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Tue Jan 01, 2013 12:48 pm

William,

I did post that hand coded binary search logic some time back. we are still using it in production. The reason we had to code it by hand is that we were emulating the START verb used against a VSAM file which we have loaded into memory and the key value which we are searching for is NOT in the array. We needed to position the array index at the next higher value if it is not found.

the SEARCH ALL verb sets the index to +1 if a not found condition is encountered. The arrays we are searching are in excessive of 450 million bytes and contain in excess of 9,999 entries so we used binary full words with the TRUNC(OPT) compiler option to generate more efficient binary math.

I would be open to running tests on any changes to that binary search routine.

thanks for the feedback. ps, i modeled that code from the examples in Donald Knuth's books.
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Tue Jan 01, 2013 1:49 pm

http://www.mainframegurukul.com/ibmmain ... 0691#10691

There is no reason for this:

Code: Select all

                       MOVE 1          TO BIN-RANGE 
It is not (I hope) used for a "flag" and the value of BIN-RANGE is always calculated irrespective of its starting value.

Of the WHEN conditions, the "equal" (finding a hit) is the least common, so why does it appear first?

Unless you load a "high key" into the table, if you look for a key higher than the final, you end up with an index outside the table. If you do load a "high key" then does the "start" need to know?

I can see you did a lot of work to get those two COMPUTEs, but did you consider trying to get them out of the "search" itself, rather than performing them every time through?

Are you really saying the table is 450MB?

Post Reply

FREE TUTORIALS

Tutorials
Free tutorials from mainframegurukul
  • JCL Tutorial
    Covers all important JCL concepts.
  • Cobol Tutorial
    This tutorials covers all Cobol Topics from STRING to COMP-3.
  • DB2 Tutorial
    DB2 Tutorial focuses on DB2 COBOL Programming.
  • SORT Tutorial
    This Tutorial covers all important aspects of DFSORT with examples
  • CICS Tutorial
    This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions



Other References
Mainframe Tools and others