× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I don't think the MONITOR op-code, which I mentioned earlier, could be used in this case since the reads are implicit.

I had problems like this: Someone would bring up a customer record for maintenance and walk away, the warehouse would try to invoice the same customer and the system would (after a minute, I think) issue an error (there was I think a re-try option). I fixed these problems by modifying the maintenance program so that, when it did the first chain, it did not lock the record but put the fields into a hold area (array in this case). Then, when the user *finally* pressed Enter, retrieved the record (with a lock), compared the retrieved record with the hold area and, if no differences, allowed the update; otherwise, sent the maintenance user a message to be a little quicker next time. Saved me long walks to the warehouse (oh, I didn't write the original programs).

It looks like the program you showed is a batch program (at least the UP says that to me). Since the batch programs are usually through with the record in less than the wait time, I never bother putting those kinds of checks there. I, also, don't bother putting the checks into things like, say, maintenance of a Ship Via Code table since the other programs that use it only access it as Input (no locks).

If you put in the PSSR routine, what do you plan to do there? As an update primary, you can't read the record again. Better to fix the cause of the problem.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John Furniss
Sent: Thursday, March 19, 2009 12:14 PM
To: RPG programming on the IBM i / System i
Subject: RE: Record lock on primary input

List,
I should have been more specific. I need to debug a program
written by someone else that uses the RPG cycle. It have the main file
open for update so it is:

FMyfile UP E K Disk

I need to trap for a locked record. Someone else has the record on their
screen and has walked away. Has anyone coded something like this?

Thanks,

John Furniss
Applications Programmer
Allied Machine & Engineering, Corp
Phone: 330-343-4283, ext. 8371
email: jfurniss@xxxxxxxxxxxxxxxxx

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rory Hewitt
Sent: Thursday, March 19, 2009 1:09 PM
To: RPG programming on the IBM i / System i
Subject: Re: Record lock on primary input

John,

Attached is a document I wrote several years ago about the *PSSR. It
gets
more complicated than you probably want/need...

Rory

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.