RE: Suggestions for replacing WRKQRY

Hi,

I do understand commitment control.  I guess I did not phrase the question correctly.

Being the STRQM displays the error QMR0151 and does not actually go into Query Manager I do not know what files would be hit by doing the COMMIT or ROLLBACK. This was messed with prior to me being here.

I do not want to do a COMMIT or ROLLBACK not know what is going to get hit.

Is there a way for me find what files are affected?

strqm                                            
Connection cannot be changed. Reason code is 1.  
START  command failed with SQLCODE -752.         
START  command ended due to error.               
DB2 UDB for iSeries Query Manager cannot start.  
DB2 UDB for iSeries Query Manager cannot start.    
   

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, May 8, 2015 10:54 AM
To: Midrange Systems Technical Discussion
Subject: RE: Suggestions for replacing WRKQRY

Jerry,

What will happen with a COMMIT or ROLLBACK is a very basic question. 
Actually I think it should be as I believe more people should be using commitment control.
However, I can understand that many people may not know this.

Let me give the introduction course to commitment control then.

First of all, let's start journalling a file.  (see CRTJRNRCV, CRTJRN, STRJRNPF, etc) After you've done that every time you make a change to that file(s) an entry is made to the journal.
Now, let's start using commitment control.  Many programs do this automatically (unless you tell them otherwise).  For example, imbedded SQL in RPG will unless you code each statement with WITH NC, meaning "with no commitment control".  Or if you add SQL's version of the H spec SET 
OPTION. And use Commit    = *None.
Now, let's say you are running underneath commitment control.  You've made some updates to this/these file(s).  They are appropriately recorded in the journal receivers.  At this time you can execute a ROLLBACK operation which says "undo all changes to this file since the last COMMIT operation".
See also the command RMVJRNCHG.  This is kind of like ROLLBACK but allows you to specify your own granularity.

Let me give a sample.
I do the following
CREATE TABLE ROB.MYTABLE (
COLUMNA CHAR (1 ),
COLUMNB DEC (5 , 2))
and I have journalling on this file.

Now I do
INSERT INTO ROB.MYTABLE VALUES('A', 2.3) INSERT INTO ROB.MYTABLE VALUES('B', 1.2) INSERT INTO ROB.MYTABLE VALUES('C', 6.25) select * from rob.mytable COLUMNA  COLUMNB
   A        2.30
   B        1.20
   C        6.25
COMMIT
Commit completed.
INSERT INTO ROB.MYTABLE VALUES('D', 5.05) select * from rob.mytable COLUMNA  COLUMNB
   A        2.30
   B        1.20
   C        6.25
   D        5.05
ROLLBACK
Rollback completed.
select * from rob.mytable
COLUMNA  COLUMNB
   A        2.30
   B        1.20
   C        6.25

Notice how that the one insert which occurred after the COMMIT is no longer there?
Understand?

In STRQM you may want to look at
10. Work with Query Manager profiles
Find your user profile.
5=Display
Look at "Commitment control level".
If you are not using journalling you may will probably have to change this to None.  This may help you avoid the message you saw when you started STRQM.

STRQM, and the option 10, will also allow you to control what SQL statements the users are allowed to run.


Rob Berendt