SEARCH ALL w/ Reference Modification

Chris Chapel · Posted: Fri Feb 12, 2010 10:38 pm

I tried to search for an existing topic (without luck I guess). I'm trying to emulate something that I did dozens of times in IBM HLASM by inserting the binary length into a OP Code for a CLC instruction, but in Enterprise COBOL.

Is this possible...using the methodology that I coded (see code block below)?

Thanks for your help.
Chris.

dick scherrer · Posted: Fri Feb 12, 2010 11:27 pm

Hello,

When you say "isn't working" does this mean there are no matches?

You might change this:

Chris Chapel · Posted: Fri Feb 12, 2010 11:33 pm

I had started with a variation of your suggestion, have the reference modifcation on the array-side and the compiler didn't like this. I thought that I still had the compiler error, but I don't. I will however give this method a try.

Thanks Dick.

Bill O'Boyle · Posted: Fri Feb 12, 2010 11:51 pm

IMHO, the ODO (in WS) can be changed to just a plain old OCCURS 100. Also, based upon the number of entries that you're loading, you'd be much better off with either a SEARCH or an in-line PERFORM. Generally, when a table exceeds 128 entries, then a SEARCH ALL is the more efficient method for table searching, providing (of course) all the table entries are sorted.

If you intend on keeping the SEARCH ALL, before you populate the table, you need to initialize it with ALL HIGH-VALUES and then load the valid table entries. What's the value of YM-DIV-ENTRIES?

But, I'm unsure why your reference modification compare doesn't work. However, COBOL (in its infinite wisdom) will NOT expand into a CLC, but rather a CLCL. This is due to the fact that the reference modification length is OTHER THAN a LENGTH OF. I know it seems silly that COBOL would not have the smarts to use a CLC, but that's the way it is. Inasmuch as you'd like to insert the length for operand-1 into a generated CLC, you can't do that in COBOL.

FWIW, the same thing happens on a MOVE with a reference modification length which is unknown (other than a LENGTH OF), COBOL will issue an MVCL, even for ONE byte! I know, it's crazy, but that's the way it is.

I had a discussion with a COBOL compiler guy at SHARE 2008 and I asked him that very question; why the CLCL, MVCL etc? He said is was because the compiler doesn't know the length until execution time and I said "Well, PL/I does", but he never gave me a good answer and dodged me. PL/I will actually generate an EX over an MVC or CLC, using the supplied length minus 1. To make it more interesting, the PL/I complier folks are on the same floor and in the same vicinity as the COBOL compiler folks. But, I guess they don't talk to one another.

But, fellow member "Enrico" said it best "Because PL/I is a smarter compiler". However, if I had uttered this to the COBOL guy, I would have gotten a coffee shampoo!

Later....

Bill

UmeySan · Posted: Mon Feb 15, 2010 3:56 pm

That's why i always prefer to code in Assembler.

If they let me do this. :-)

Chris Chapel · Posted: Mon Feb 15, 2010 8:00 pm

Bill, thanks for your advise on the suggested threshold to apply the binary versus serial search. I've heard many suggestions in the past 15-20 years (most of them significantly smaller than 128 entries), but have never performance tested the theory.

Regarding the initialize with ALL HIGH-VALUES, that would be required on a search with a "static" number of entries, but w/ the ODO clause, the scope of the search is limited to the value presented to the ODO clause (which in this case is: 12 - the number of records from the input-loading table which is stored in YM-DIV-ENTRIES).

As I mentioned following Dick's reply, I tried the reference modification on the array-side of the WHEN... clause and received the following compiler error.

dick scherrer · Posted: Tue Feb 16, 2010 12:14 am

Hello,

I was afraid of that. . . Bummer.

Did you try this without the ODO? Again just an experiment.