Re: SQLRPG/*DFTACTGRP Problem

Okay, I've got some more information -- after doing some tests, I found
that the problem seems to be with commitment control -- when I added a
"set option commit=*none" statement to my OPM program, the problem went
away. But I still wonder what was going on here, since the SQL statement
was a simple select, and I had even declared the cursor as "read only" for
performance reasons. Why do I also have to turn off commitment control,
but only in OPM?

I guess if nobody answers that means everyone else is as baffled as I am.
. . . :-)

Thanks very much,

midrange-l@midrange.com writes:
>Hi everyone,
>
>I apologize if I would better post this to the RPG-L list -- I'm not sure
>just where the problem is, so I figured I'd start here. I've got an OPM
>SQLRPG program (simple selection displayed on a screen) that is called
>from an ILE program. It's been working for months, but all of a sudden
>this morning it broke -- no selection was being made, and the screen was
>blank. I discovered that the SQLCOD was -501 (cursor not open), and when I
>checked the job log I found:
>
>. . .
><some stuff about not finding QUSRSYS/QAQQINI, which hasn't ever been
>around (?)>
>Unable to retrieve query options file.
>**** Starting optimizer debug message for query .
>The OS/400 Query access plan has been rebuilt.
>All access paths were considered for file @FRT.
>All access paths were considered for file @MBM.
>All access paths were considered for file IAI.
>File @FRT processed in join position 1.
>File @L26 processed in join position 2.
>File @MBM processed in join position 3.
>File IAI processed in join position 4.
>Commitment definition *DFTACTGRP not valid for open of @FRT.
>Object @FRT in BPCSF type *FILE has a pending change.
>Cursor C01 not open.
>. . .
>
>Am I correct in thinking that the important lines are the third and second
>from the end? On a hunch, I converted the program to SQLRPGLE and
>recompiled it with no other changes, and now everything works fine. But
>I'm curious -- since it was working fine before, what made it break, and
>why did recompiling it as ILE fix it? From what I can tell, @FRT was not
>in the process of being changed (it's locked by the menu system), and I
>didn't see anything in the log about it.
>
>Does anyone have any ideas? Thanks very much!
>
>Mike Naughton


Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com