RPG DS to retrieve User Id fails in database trigger program

[TerryB]

This is one is likely so strange it may not apply to anyone else. I use physical file trigger programs on key files to trap changes for auditing. Not sure how widely that technique even used.

But this is so strange I can hardly believe it myself. I have a Val app that releases planned Mfg shop orders, multiple orders in one post to server. It passes in array of items/qty to open order for. The server side RPG just loops through array, then calls (old school call, no ILE procedures) a standalone program that creates the Shop order and it's operations.

That program correctly retrieves the User Id the Val program is running under (VVCALL driven) and writes correct user id to the Shop Operation file for each shop order. No problems.

But when trigger fires and it calls trigger program (RPG), the first order is correctly updating with real user id. But orders 2,3 etc all get written with QTMHHTTP as user, not the real user id. I've noticed a 3-4 second delay in the time stamp written to audit file by trigger pgm from 1st order and the 2nd one. Everytime. But all orders after the first one all have exactly same timestamp, to the second.

I have many trigger programs in use here but this is only app where multiple calls to same creation program is done. All the others you are always just creating one vendor or one customer. Those all update the correct user id everytime.

It is only this repeated call that causes this. My guess is only IBM could figure this out but thought I'd put this out here just in case.

[robert.swanson]

Looks like it's pulling the job user rather than the current user... What technique are you using in your RPG program to retrieve the userID? It's definitely best to NOT use the SDS for that.

This old forum post may be helpful.

[TerryB]

Hi Rob! You missed the key issue in my rambling post: the first time this trigger program is called/fired from the same CGI post with array of items to open orders for, it correctly writes the "real" user running the program. I'm using correct spot in the data structure to get User Id that works with the Val user id swap, made that change long ago in all my programs.

It's only the orders after the first one which then start writing QTMHHTTP as user, from this same program. Yeah, impossible. :) But its happening. That's why I'm sure this is O/S level thing, who knows how IBM handling invocation of this trigger process for optimization purposes. It's not a coincidence that 3-4 seconds elapse on timestamp between first order audit timestamps and the orders after it. It's like it's setting up some infrastructure to optimize these trigger requests. That's why I maintain it is likely only IBM could fix, assuming they even consider it a bug. They should, I shouldn't get two different results reading same area of that data structure.

[robert.swanson]

You're probably right that it's an OS bug at play with the current user vs job user in the SDS.

Have you tried the inz(*user) subprocedure approach referenced in that link instead of using the SDS? That would be the only suggestion I can offer, beyond opening a ticket with IBM.

[TerryB]

Ahhh, I should have read your old forum post before responding. I think this is exactly describing the behavior here. My instincts were right to reach out to you guys.

I'll make change in a little while and post back the results once I can verify. Thanks Rob!