Thanks for the help, Charles. A co-worker of mine actually figured
out the COMMIT keyword in the F-spec line this morning, but it's nice
to have it confirmed. The amazing thing is we've been having this
problem for about a year, and IBM support has failed to give me this
simple answer after hours of back and forth and save files, etc.
Thanks again,
Lucas
> RPG's been around longer than commitment control. Thus, it doesn't
> default to using commitment control as SQL does.
> You need to make sure that the files you are using in RPG are marked for
> commitment control. Make sure the COMMIT keyword appears on the file's
> F-spec line.
> Also, when calling an RPG program from a 5250 command line you need to
> issue the STRCMTCTL command to establish the commitment definition. I
> _believe_ that in your scenario this would not be required since I assume
> that you've already established the commitment definition via ADO.
> HTH,
> Charles
> > Hi,
> > Has anyone had any experience calling RPG from VB with VB handling
> > commitment control? When I call SQL stored procedures from VB and
> > call a Rollback from my ADO connection in my VB code, the rollback
> > works fine. However, when I call an RPG program that updates data and
> > call a Rollback from my ADO connection in my VB code, the data updated
> > by the RPG is not rolled back. When I look at the journal, there is
> > no Start Commitment Control or Begin Commitment Control (and obviously
> > no Rollback).
> > The activation group of the RPG is set to default activation group
> > (I've tried caller too without success - should be same anyway). I've
> > tried different isolation levels on my VB connection as well.
> > Any ideas?
> > Thanks,
> > Lucas
by