Re: File Trigger Performance

On 2018-04-09 1:27 PM, Denis Robitaille wrote:

I would also avoid *CALLER. Because multiple job can initiate the trigger so may have several activation group. Probably not a big deal though.

If you are willing to change the code of the trigger program, here is a suggestion:
- Add a table to the program that hold the jod id (number, name ...) and it's type (batch/interactive)
- When the trigger is called, check to see if the job is already in the table
- if so, retrieve the type of job from the table
- if not, call the API to retrieve the type of the job and add this information to the table

This way you will call the API just once per job instead of once per read. My guess is that is where you will get the best performance boost.

The trigger program could also be changed to add another module written in a language that supports static variables (any ILE language besides CL, I think). The second module could have one procedure to save the "return_immediate" value, and another procedure to retrieve it, either some value that means "not known yet" or the saved value. I think that would perform even better than the file, and be somewhat simpler too.

Something like this, untested:

CL:
dcl &ret_immed char(1)

callprc get_ret_immed parm(&ret_immed)
if (&ret_immed *eq '?') then(do)
... get batch or interactive
... read data area
chgvar &ret_immed to either 'Y' or 'N'
callprc set_ret_immed parm(&ret_immed)
enddo

if (&ret_immed *eq 'Y') then(return)

If RPG is the other language:

dcl-pi *n;
ret_immed_parm char(1) const;
end-pi;
dcl-s ret_immed char(1) inz('?');

dcl-proc set_ret_immed;
dcl-pi *n;
ret_immed_parm char(1) const;
end-pi;
ret_immed = ret_immed_parm;
end-proc;

dcl-proc get_ret_immed;
dcl-pi *n;
ret_immed_parm char(1);
end-pi;
ret_immed_parm = ret_immed;
end-proc;