Calling Subprogram only once.

venuhunev · New User Joined: 26 May 2007 Posts: 70 Location: chennai

Hi,

I have a program say Program XYZ will be called numerous times in production from main program say program ABC.

In sub program XYZ, to increase performance, Values are selected from DB2 database tables and stored in an internal program array.

I have a requirement where the array should be only populated once. That is, logic in the program should be such that it detects whether the values have already been populated in the array and should remain static each time the program is called.

How to do in PL/1 ?

Kindly Help. Thanks.

prino · Posted: Sun Mar 06, 2011 12:49 pm

venuhunev · New User Joined: 26 May 2007 Posts: 70 Location: chennai

Hi Prino,

Thnx for your reply.

Your code shows that xyz is called once and array value is fetched and used only once in main program.

But my question is, ABC calls XYZ in loop and Array is populated from DB2 tables and used in XYZ It should not be populated in all loops, only once inside the sub program.

enrico-sorichetti · Posted: Mon Mar 07, 2011 12:10 am

to clarify Robert post

since we do not know the details of the subroutine, You were given a general hint...

split the subroutine in two parts

part one to be called outside of the loop to initialize the array,

inside the loop just use the array already filled ( Robert snippet)
or call the subroutine doing the process-only part!

prino · Posted: Mon Mar 07, 2011 12:15 am

Your requirements are as clear as mud, not surprisingly... My solution matches them.

Can you tell me why my solution does not match your requirements as given in the first post of the thread?

enrico-sorichetti · Posted: Mon Mar 07, 2011 12:19 am

the TS is confused... he seems to believe that the i is the index of the array !

venuhunev · New User Joined: 26 May 2007 Posts: 70 Location: chennai

ok.

I ll make my requirements very clear.

dbzTHEdinosauer · Posted: Mon Mar 07, 2011 6:02 pm

regardless of programming language:
step two (2) should in addition to populating the array, set a flag.
then subsequent calls to the module would check the flag, and if set, skip step2.

you can declare a flag, initialized to 'no' or 'off' or 'notset'.-
end of step2, set the flag to 'yes', 'on', 'set'.

if you can't make that work, you can't keep the table populated between calls.

enrico-sorichetti · Posted: Mon Mar 07, 2011 7:18 pm

don.leahy · Posted: Mon Mar 07, 2011 9:07 pm

I am not a PLI programmer, but my favourite way of approaching this problem is to code the subroutine to behave as follows:

prino · Posted: Mon Mar 07, 2011 9:17 pm

And by keeping the array "small", you can improve the efficiency even more by using a simple LRU algorithm to keep the most used values in it. (With "small" empirically defined based on the cost of going to DB2 vs the cost of looping through the array)

In PL/I you could conceivably even sort the array in a separate thread and use a binary search on it, although that might increase CPU use too much...

Ronald Burr · Posted: Mon Mar 07, 2011 9:50 pm

So much depends on the specifics:
The TYPE of table lookup (direct vs binary vs sequential) can be influenced by a number of factors, including:

1) the class of the table argument (numeric, alphanumeric) and
2) the range of possible argument values

For example: if the arguments are numeric and the range is from 1 to 1000, it may make more sense to store and access table entries using the argument itself as a subscript into the table.

3) the frequency distribution of argument

For example: if the argument is state-code and you are processing payroll data, it may make sense to populate the table in descending order by the number of employees in each state and perform a sequential search.

4) the maximum number of arguments possible vs
5) the average number of arguments accessed

For example: if there are 5 million possible argument values, but the average number accessed in a given run is only 5,000, then it may make sense to create a "sparse" array, in which only actually used arguments are stored (for future reference) rather than all 5 million. In some cases, it may make sense to "pre-scan" the input to normalize the actual argument values that will be used, and build the lookup table for just those arguments.

6) The order of the input arguments

For example, if the input is pre-sorted in ascending argument value, then it may make sense to not have a TABLE at all - as each search is initiated check to see if the argument matches a stored entry - if it does, you already have the result; if it has changed, retrieve the appropriate result, and save the argument and result for the next search.

prino · Posted: Mon Mar 07, 2011 10:06 pm

Even a mixed approach is possible when the distribution is extremely skewed, as, for example here in Belgium, with members of Belgian health insurers. About 97% of their members are Belgian, 1% are Dutch and French and the rest is the rest. By doing a linear search on B/NL/F followed by a binary search on the rest, processing was sped up enormously.

The old situation? Would you believe it? An unsorted array, with B somewhere past the middle...

don.leahy · Posted: Mon Mar 07, 2011 10:19 pm

Prino, Ronald, thanks for rescuing a thread that wasn't going anywhere. Sometimes even a "dumb" question can lead to an interesting discussion.

PeterHolland · Posted: Mon Mar 07, 2011 11:38 pm

Belgium is a not existing country. Half of it is french, half of it is dutch.
So how about distribution?