RE: Record-lock scope question

As long as a program has the record locked for update no other program will be 
able to update it.

I see two options.

1) Move the update of the file from both programs into a third.  Let the third 
handle making the updates on behalf of the other two.

2) Make use of commitment control.  You could keep the record locked by the job 
(but not the program) until you issue the commit.  This would prevent other 
jobs from changing the record.

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 Pascal Bellerose
Sent: Tuesday, October 24, 2006 10:55 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Record-lock scope question

Hi,

I have a problem where I have a program that locks a file for 
update purposes, and then calls a second program that needs 
to update the same file, same record.

Is it possible to use something like an OVRDBF or whatever 
that could let the second program do his chain/update?

But at the same time, we don't want another job to update the 
same record.

Right, now we're projecting to use a second file that would 
be used to manage locks but I don'T like that idea and I'm 
pretty there is something in OS/400 that does the trick.

All you wizards out there, I summon the mad genius in 
yourself, and I do beg for an answer!

Thanks in advance!

Pascal Bellerose
pascal_bellerose@xxxxxxxxxxxx
Réseau/Network: 2114

Équipe de support TI Corporatif / Corporate IT Support team
Tél./Phone: 819-363-6100
Fax/Télécopie: 819-363-6155

 

Cascades Canada inc.
412, Boul. Marie-Victorin
Kingsey-Falls, PQ, Canada
J0A 1B0
-- 
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.