Re: How to merge 2 customers into 1? -- RPG400-L

Yes.

In fact, even when you "regularly use" commitment control, you have to
start it in each job at least once using STRCMTCTL. You can also end
it using ENDCMTCTL. (Unless you're using embedded SQL)

Note however that the use commitment control requires that the files
be journaled. If your files aren't already journaled, you'll need to

Create Journal Receiver (CRTJRNRCV)
Create Journal (CRTJRN)

then Start Journal Physical File (STRJRNPF) on each file involved.

You can End Journal Physical File (ENDJRNPF) afterward on each file if
you want along with deleting the receiver and the journal if you
really want to.

HTH,
Charles

On Tue, May 4, 2010 at 8:08 AM, Robert Rogerson <rogersonra@xxxxxxxxx> wrote:

Keith, just a quick question on committment control.

If committment control is not regularly used, but desired as in the scenario
you described, can commitment control be turned on for the duration of a
process and then turned off again when the process is complete?

Thanks,

Rob

On Tue, May 4, 2010 at 5:15 AM, McCully, Keith (Insurance, Technology
Services) <Keith.McCully@xxxxxxxxx> wrote:

It would better to group all the updates for a particular customer into
a transaction with a single commit control boundary. That way, if all
updates for the customer worked then go ahead and commit the updates to
the database but, for any failures, rollback all the updates and proceed
to the next customer. So, either way, you will have all the records for
each customer in the same state. Also, if failed, write a line to an
error log to highlight the error and assist recovery although a manual
recovery on up to 30 files seems painful!

It would also be possible to run as EOD background job rather than
interactively - depends how quickly you want the update.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of David FOXWELL
Sent: 04 May 2010 08:17
To: RPG programming on the IBM i / System i
Subject: How to merge 2 customers into 1?

Hi,
I'm looking for advice and/or opinions on this method :

A user can display a list of clients sorted by name and date of birth in
a subfile. If all the names and dates of birth are equal for two
clients, the user has an option that will merge the 2 clients into one.
This means that one client number will become obsolete. There are about
30 different files in which the obsolete client number is replaced by
the remaining client number. After confirmation by the user, the program
loops through a file that contains the files to be updated. For each
file information is extracted to create and execute an SQL update. If an
error occurs on the update, a message will be displayed to the user but
the program continues the updates on the remaining files. The user will
see at the end that at least one file update failed. We've just had a
case where this happened, and I must say I am rather surprised at this
method of merging the clients in an interactive application, but I am at
a loss to think of a better way.

I am interested to read how others have resolved this problem.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

*** WARNING : This message originates from the Internet ***

The Royal Bank of Scotland plc, Registered in Scotland No. 90312.
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB

Authorised and regulated by the Financial Services Authority.

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message from
your computer. Internet e-mails are not necessarily secure. The Royal Bank
of Scotland plc does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will not
adversely affect its systems or data. No responsibility is accepted by The
Royal Bank of Scotland plc in this regard and the recipient should carry out
such virus and other checks as it considers appropriate.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.