Oppolzer - Informatik / Blog

After writing this, it became clear to me, that some further explanation may be
needed.

Of course, if you have n read only tables, and for every table in average m
requestors, you will have n * m binary search logic blocks in your system, if
you do the binary search at the requestor's side and not at the providers side
(that is, in the table module) ... which is much more.

But: if you are able to parametrize your binary search in a way, that all
relevant informations (starting address of the table, number of elements, size
of an element, position of the key inside an element, length of the key) are
variable, then you need ONLY ONE binary search logic for your whole system,
which covers all your read only table ... and this is what we did in our old
ASSEMBLER based system. So we had the binary search logic only in ONE place in
the whole system ... at least for those read-only tables containing the business
information for the life insurance.

Now, when moving to the C solution, we generated individual binary search logic
in C which is part of the read only table; that is, we have it n times. Given
the number of tables (some hundred), and the size of the binary search logic
(some hundred bytes), this is no big problem.

Kind regards

Bernd



Am 20.03.2015 um 13:25 schrieb Bernd Oppolzer:
> In our old insurance math system, based on ASSEMBLER, we had lots of read only
> tables, which were implemented as load modules like this. The modules that used
> this modules, LOADed them and looked up the information in the modules based on
> the address in register 0 returned by LOAD.
>
> When implementing the new math system in C, we took a slightly modified approch:
> the table modules now had large static const array with init values, and they
> contained a small function, which did a binary search on this tables, so the
> function delivered the needed values based on keys passed as parameters. The
> modules now are "normal" C functions. But from a functional point of view, it is
> almost the same.
>
> In a sense, the old approach was smarter, because the binary search had to be
> coded only once ... with the new approach, every table module contains the
> binary search logic ... but that does no great harm, because the table modules
> are generated, and the code is not very large.
>
> Kind regards
>
> Bernd
>
>
>
> Am 20.03.2015 um 13:16 schrieb S.F.:
>> E.,
>>
>> Ty my friend, I worked in manufacturing for awhile we had an external table
>> like this we loaded into CICS. Those were the days of macro CICS.
>>
>> Thanks my friend.
>>
>> Regards,
>>
>> S.
>>
>> On Friday, March 20, 2015, E.E. wrote:
>>
>>> E.E. wrote:
>>>
>>> I have the same thing which Charles Mills kindly described. Load a mod
>>> with data and play with it.
>>>
>>> In my case, I inherited an ancient IEFUJI exit. That thing loads a module
>>> residing in a linklist library which contains only a list of approved
>>> accounting codes allowed to be used.
>>>
>>> As promised here is it (As you can see it was ancient stuff... ;-D ):
>>>
>>> This load a mod and use R4 as a base to loop the table.
>>>
>>> A00UJI   EQU   *
>>>          LOAD  EP=SSPACTCD
>>>          LR    R4,R0                 SAVE EP ADDR
>>> A00LOOP  EQU   *
>>>          CLC   0(5,R4),PROJECT       IS THERE A MATCH ?
>>>          BE    A00SPEC               YES
>>>          CLC   0(5,R4),=C'FFFFF'     END OF TABLE
>>>          BE    A00INV2               NO
>>>          LA    R4,8(,R4)             SCAN THROUGH TABLE
>>>          B     A00LOOP               NEXT ENTRY
>>> ....
>>> A00INV2  EQU   *
>>>          WTO   'IEFUJI04 NOT REGISTERED CONTACT SYSTEMS'
>>> ...
>>>          BAL   R10,A00DELEP
>>>          LA    R15,4              4  CANCEL JOB PROCESSING
>>>          B     A00EXIT
>>> A00SPEC  EQU   *
>>>          BAL   R10,A00DELEP        0
>>>          LA    R15,0              CONTINIUE
>>>          B     A00EXIT
>>> A00DELEP EQU   *
>>>          DELETE EP=SSPACTCD
>>>          BR    R10
>>> ...
>>> PROJECT  DS     CL5
>>>
>>> Table linked in Linklib as RENT.
>>>
>>> SSPACTCD CSECT
>>>          DS    0F
>>>          DC    CL8'ABCDE'
>>> ...
>>>          DC    CL8'FFFFF'   END
>>>          END
>>>
>>> Groete / Greetings
>>> E.
>>>
>>> ----------------------------------------------------------------------
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to listserv@listserv.ua.edu <javascript:;> with the message:
>>> INFO IBM-MAIN
>>>
>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN