Re: Recognising a particular job

Hi Stuart,

Thanks for your reply.
Yeah I have used that approach before. In fact I used it this time when I
thought I could get away with leaving the program active and only call it
once. But sadly not.
I believe though, that the qmhsndpm fail generates additional stuff on the
calling program queue ( CPF2479 call stack entry not found, CPF2469 Error
occurrend when sending message.. ) which would also need to be removed if I
didn't want to be generating massive joblogs.

It happens that in my situation, the server jobs in which I don't want to
generate messages when the trigger fires, are already confined to their own
subsystem and have their own job queue.
So I think I might use this in order to make the determination by using
QWCRTVCA to retrieve job attributes and get the JOBQ name.
This has tested ok - it returned exactly what I was expecting and calling
it 10,000 times takes around 1 second so that's pretty decent.

It's a pretty simple API but if anyone has a requirement or interest, give
me a shout and I'll paste some example code.

thanks and regards,
Craig

On 23 February 2018 at 00:20, Stuart Rowe <rowestu@xxxxxxxxx> wrote:

Craig, the qmhsndpm to a call stack entry is very fast. When it fails,
program not in stack. When it succeeds, qmhrmvpm and it goes away, it will
not fill up the joblog.

On Thu, Feb 22, 2018 at 3:18 PM, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

Hi Buck,

Thanks for your reply.

My situation is similar to the one you describe when it comes to
performance specs too.
At the moment the performance that the web client is seeing is not
spectacular but probably fast enough.
I worried the delays might be with the QTMHHTP1 thread having to connect
and disconnect to the remote database all the time, inserting records

with

CLOBs and using final table to retrieve IDs from auto-gem columns on the
remote box and start up the trigger programs but in fact all of that

stuff

is surprisingly fast and by far most of the transaction time is occurring
in the web server.

I guess I'll run some tests on that API tomorrow, I just wanted to make
sure there wasn't a more obvious simple solution.
I still like the sndpgmmsg solution and I believe it's more lightweight
except it fills the joblog. I could of course remove successfully sent
messages...

Maybe I'll compare those two...

While it might sound a bit naive to suggest a solution like identifying

it

by the user profile of the job and restricting the use of that profile to
those server jobs still has its merits if you have sufficient control

over

things like that in your application.

Thanks as always to all who take the time to reply :-)
I know we are all busy and it's good to throw some ideas around.

best regards,
Craig

On 22 February 2018 at 20:32, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 2/22/2018 2:30 PM, Craig Richards wrote:

And I fear that the call stack one is a bit expensive to do every

time

Don't fear the expense - measure it.

If you implement the 'who triggered me' code as a sub-procedure, you

can

swap out different methods very quickly. Run a hundred thousand tests
of each method and you'll have reasonable numbers with which to base a
decision.

Along those lines, it can be very enlightening to instrument all of the
various sub-procedures / code blocks. I found my intuition wasn't

as...

precise as actual elapsed time measurements.

Speaking of actual time, does your organisation have a performance spec
for this application? The closest my organisation gets to a

performance

spec is vague hand waving when something 'is taking too long'. The net
result is that performance requirements tend to be somewhat more
flexible than I myself start off believing.

--
--buck

http://wiki.midrange.com
Your updates make it better!

--
This is the RPG programming on the IBM i (AS/400 and iSeries)

(RPG400-L)

mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD