RE: Commitment Control

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

Jim,

Yes, sequence objects are new to v5r3.  v5r2 added a similar but different 
IDENTITY column type.

You may be able to use that.

As far as journaling being overkill....I wouldn't say that.  You could journal 
the one file without putting any noticeable drain on your system in terms of 
DASD or CPU usage.  In fact, you could probably journal all your files without 
taking a noticeable hit to performance.  The idea that journaling is bad for 
performance has not been true for some time now.  There may be a few 
environments where journaling has a noticeable impact, but there are a few 
options to help there.  In fact there are some environments where journaling 
actually increases performance!  DASD usage would increase, but at v5r2, there 
are a considerable number of options to lowest the DASD requirements.

So, either use SQL and commitment control, which requires journaling.

The other option is to use record level access, either via RPG or I think an 
SQL cursor would work too.


HTH,

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Reinardy, James
> Sent: Thursday, May 05, 2005 6:21 PM
> To: Midrange Systems Technical Discussion
> Subject: RE: Commitment Control
> 
> 
> Rob,
> 
> We are currently on V5R2.  Are sequence objects new with V5R3?  I have
> used them with Oracle, but never thought of looking for them 
> in DB2 for
> some reason.
> 
> Thanks,
> 
> Jim 
> 
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> Sent: Thursday, May 05, 2005 5:08 PM
> To: Midrange Systems Technical Discussion
> Subject: Re: Commitment Control
> 
> What version of OS/400 are you using?
> Why not use a Sequence object?
> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/i
> nfo/db2/rb
> afzmstdatetimearith.htm#seqref
> 
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
> 
> 
> 
> 
> 
> "Reinardy, James" <jreinardy@xxxxxxxxxxxxxxx> 
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 05/05/2005 04:58 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> 
> 
> To
> "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> cc
> 
> Subject
> Commitment Control
> 
> 
> 
> 
> 
> 
> Looking for some advice.  We have an application that uses a 
> table entry
> to get the next available number for an ID field used in a series of
> tables.  This number is used in both an RPG and a Java program, and we
> are concerned about ensuring that the same number is never 
> issued twice.
> My thought was to write a user defined SQL function that 
> would increment
> the table value and return the next number, using commitment 
> control to
> ensure that the row was locked for the entire process.  We got the
> function created, then figured out that we needed to journal the table
> in order to use commitment control.  We are not journalling 
> anything on
> the box today for performance and data storage reasons and at 
> this point
> would prefer to avoid it. 
>  
> Is commitment control overkill in this case?  We are using an update
> cursor to perform the operation, so will that keep the record 
> locked for
> the duration of the function execution?  If not, is there 
> another way to
> do this gracefully without commitment control and journalling?
>  
> Thanks in advance,
>  
> Jim Reinardy
> Badger Meter, Inc.
> Milwaukee, WI
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing 
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>