Or the logicals could be in different libraries for each office and the user library list determines what rows they see.

That’s consistant with the manual .. it reads the last record of the set, processes that record and then attempts to read the next record in the file which it will then discard as the wrong key.One answer (also lousy maybe worse) .. logical files – one for each office .. and override to the logical.  Since the logical selects only for the records of that office it reaches EOF, instead of trying to get the record from a different office.

That might be something like this:  If(F9>35000,35000*0.35 + (F9-35000)*0.10,F9*0.35) 

Thanks for your help.  We’ll follow-up with IBM as suggested. To answer a couple of questions…The first code sample is typical of what encounters a lock.  The joblog identifies the locked RRN.  The record turns out to have a non-matching key.  Logging shows that the second code sample resolves the problem.  (We see no new unexpected log entries for a given program after it is revised.)  It is consistent with the manual, but the idea of fixing 20+ years of programs is daunting.  Maybe we’ve just been coding wrong for our entire careers and didn’t realize it.  Maybe that is the question I’m really asking.It has become an issue because we have branch offices in several states.  Many of our programs monitor for locks and display a message when one occurs, giving the user the opportunity to retry. Legitimate locks typically happen within a single branch and users can sort them out without calling the help-desk. A problem scenario goes like this:  Ohio calls to report that Florida has an Ohio account locked.  Ohio wants to know what Florida is up to.  Looking at the specific RRN, the record is a Florida account with completely different key values.  Using a service job to debug the Ohio program, we see nothing odd — the READE key values match the Ohio account.  We can’t understand why it wants the Florida record. Florida releases the lock, Ohio retries, the READE completes, and EOF is on.  (Again, consistent with what the manual says can happen occasionally, but something we don’t recall having issues with.)Maybe it has to do with sheer volume.  Our main order-entry driver is called about 10,000 time per day on average.  Unexpected locks within that system occur between 1 and 10 times a day.  Even at once per day, it’s not fun trying to reassure Ohio that Florida is innocent.

Up front costs are the biggest hurdle. This is especially true concerning shared storage. I recently researched the costs of implementing a shared storage solution for our mission critical application servers. I was truly gob smacked. T

Or you can chain into any SFL record with a field structured like RRN for the key.

oddly enough I ran into problems a few versions ago with READ(N) where it appeared that the process was actually a read with lock followed by an unlock.  At that time READ(N) would get record locks.  Obviously, IBM doesn’t think that’s the case, since they recommend a READE(N) in the solution to the locked record case.

Wow — there’s a lot of bad code out there .. I’ve certainly created my share.Always thought that READE was a database function .. instead of a shortcut for a READ and an RPG compare.

here a link. It was very helpful for me. Quick and easy tutorial for the admin rights.
https://www.youtube.com/watch?v=CvMmVKZq1Vo

i think it’s an invisible add-on, as i had no add-ons listed. microsoft helpline
did a reset on ie and problem solved. tools > internet options > advanced
> reset. did not lose favorites!

I agree, though, that checking with IBM is a good idea. If the behavior really changed in 7.1, then related PTFs might already exist. If not, one might need to be created. — Tom

The same issue is in earlier releases, though the documentation wording has changed. In V5R3, for example, the word “occasionally” is not included. The implication would be that it always happened in the past, but now it only happens “occasionally”. I asked about what program sees the error because it wasn’t clear if the ‘temporary’ lock was seen to interfere with another program or if this.program was reporting that it was unable to set the ‘temporary’ lock. — Tom

When you write a blank subfile record (or write any subfile record), you can write it with the SFLNXTCHG (Subfile Next Changed) attribute enabled. That will cause that record to be read by the next get-next-changed operation even if the user did not make a change. It would have to always be on for every blank record if I understand correctly, so it seems a little pointless. You might as well just use a straight READ and skip testing for changes. — Tom

It's very odd, I had no idea 7.1 had this issue.  

ahhh here's some more about READE  

For duplicate keyed files, the ILE RPG language performs 

a READ NEXT operation and compares the key of the 

returned record to determine if the record qualifies. 

If so, the record is returned to the program; 

if not, an end-of-file indication is returned  

So your fix is the recommended fix in the manual..

I think you need to contact IBM and see if they have a fix 

coming out.  I don't believe that this was the way previous

versions worked.

There’s no way for us to know if you don’t tell us what kind of files they are. An extension is no guarantee of anything since anyone can put any extension on any file. There are at least five different applications that are known to use a .NIF extension. Which one are you working with? And since .NIF files usually are no good to anyone who doesn’t know what to do with them, can you describe how you would use them on a Chromebook? That might help in narrowing possibilities. — Tom

You may be correct, however, the same code is running on over 150 different AS400s and only 1 has an issue bringing up a window. I just thought there might be a system setting somewhere. Thanks for the input. Just thought I’d check.

Can you define “the associates”? That’s the first use in this thread. Proving inadequacy only takes locating a single unprotected critical system resource through any non-menu interface. The locating should be demonstrated using a general user profile. But saying how to do it requires showing how to determine which resources are important on your system and then teaching the generally available non-menu access methods. That becomes a system analysis task first and a general course in networking second. Neither is trivial. If the teaching doesn’t happen, then there’s no way to support any evidence with authoritative documentation. By running a dedicated tool from a respected vendor, you at least have evidence that says whether or not actual analysis is needed. It’s very hard to take the next steps otherwise. — Tom

Thanks very much, AndreaF.

The clients access the AS400 through a Windows domain. What I’m mainly having an issue with is proving that there is indeed segregation of duties between the associates or that the current setup is inadequate. 

For “Special Authorities”, there should be a couple general profiles that have them though the distribution of those across the few profiles is up to the needs of the system. In general, there is no need for any non-administrator or non-supervisor profile to have any of the ‘special authorities’. If a general user demonstrates a need for one of those assigned to their profile, it’s almost certain to indicate flaws in the security scheme that has been set by system administrators or application developers. These flaws might arise from applications that are many years old that have never been modernized. You might consider a tool such as PowerTech’s Compliance Assessment for a review. Other tools from other vendors are available, but I’m not familiar with them. — Tom