RE: RPG programs as external stored procedures...

" A named ACTGRP could work in server mode (for example called from ODBC/JDBC) as expected (I'm a little bit unsure, if the commit would have to be wrapped in a stored procedure),"

In those cases, I do the commit from within my RPGLE code. I'm not sure what would happen if the client tried the commit directly.



-----Original Message-----
From: D*B [mailto:dieter.bender@xxxxxxxxxxxx]
Sent: Monday, February 19, 2018 11:11 AM
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Subject: Re: RPG programs as external stored procedures...

<Justin>
I saw your post about commit boundaries. When I think of external
stored procedures, I think of ODBC/JDBC callers. In those cases, I
think a named activation group would be fine, since every call would
have the same activation group. I guess I could see issues if the
caller was ILE and you wanted to share a commit between the calling
ILE and the external stored procedure. Although, that sounds
incredibly rare to me, and I'm not even sure how that would even work.
</Justin>

... a stored procedure doesn't know, where it is called from (and it shouldn't care about). A named ACTGRP could work in server mode (for example called from ODBC/JDBC) as expected (I'm a little bit unsure, if the commit would have to be wrapped in a stored procedure), but it would behave very diffrent in the AS/400 native environment (pending record locks, changes could disappear at end of ACTGRP...). Sharing a commit between a native programm and a stored procedure is working like any other commit: Running the slave in *caller, the commit will free all resources and make the changes permanent, Running the slave in a diffrent ACTGRP, the commit will only work for the ACTGRP, where it was issued.

D*B