If the IN operation is really the problem then an alternative option is to use User Spaces to replace the data areas.

Because they can be resolved via a pointer they are just like any other memory in the program and require no operation to "see" the current data. If there is potential for more than one program to update the space then you might want to implement some "in use" semaphore to ensure that the updates don't screw each other up.

On Nov 13, 2019, at 9:15 AM, Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

We have the same Trigger Program (in RPGLE) defined on multiple files,
which get updated from multiple different jobs. The program writes an entry
to a data queue. The total updates to all the files easily exceed a billion
a day.

I have a few questions. How is the program invoked on file update? Does it
always get a fresh copy? If not, is it possible to code something which
will execute only once?

What I am trying to do is this: The program is reading 4 data areas using
'IN' statement. I have found that the IN statement is about 7-8 times more
'expensive' than CHAIN. I am trying to figure out if there is a way to
increase the efficiency of the Trigger program. All the 4 data areas are
really static, but CAN be changed, hence the 'IN' statement for every cycle.

Any ideas will be greatly appreciated.

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.