error occurred while update my PF using rpgle program

3790 pts.
Tags:
as400 pf file
as400 v5r3
RPGLE Program
i got one error, while update my PF using rpgle program.....
i have done all file operation in one single program. all operation working fine. but update operation didn't working, i got below error..
"subsystem Update or delete in file EMPLOYEE without prior input operation (C G D F)."
please give a suggestion for my proble...   


Software/Hardware used:
as400 v5r3

Answer Wiki

Thanks. We'll let you know when a new response is added.

while update my database, it ll show error, if i use the read(n) and readp(n).
as well as using same field name in database and display file..
so just change like this:
<pre> if *in05=*on
empno chain emp
eval empno=empno1
eval empname=empname1
eval salary=salary1
eval city1=city2
eval phoneno=phoneno1
update emp
endif </pre>
empno, empname, salary, city1, phoneno -> database file field name
empno1, empname1, salary1, city2, phoneno1 -> display file field name

for delete operation:
<pre>C empno chain emp
C delete emp </pre>

Discuss This Question: 29  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • philpl1jb
    When you read or chain a record it stays locked for update provided the read or chain doesn't include an (n) for no lock. It will be locked until it's updated or another row is acquired through the access path or the row is updated or unlocked. It you try to update the row when it isn't locked you get the error message you got. - didn't read/chain record - already updated recrod - unlocked record - never locked record Phil
    51,365 pointsBadges:
    report
  • pdsathishkumar
    Mr. Phil, i got your hint, but i want to do the read, read previous and chain operation without record lock. because my program will access by many user simultaneously. how can i solve this problem...
    3,790 pointsBadges:
    report
  • philpl1jb
    Yes, that's excellent muti-user design Always do the chains and reads with no lock. Just prior to updates do a chain with lock, that is without the (n) nolock - if the chain is successful do update. Phil
    51,365 pointsBadges:
    report
  • pdsathishkumar
    Just prior to updates do a chain with lock, that is without the (n) nolock Mr. Phil, i can't get you point clearly, please give me a some examples....
    3,790 pointsBadges:
    report
  • philpl1jb
    Don't know how much clearier I could be If your program has an update or delete command It should be preceded with a chain to acquire and lock the record to be updated Chain ( keyfl1 : keyfld2) MyFile; // get record and lock it //Update fields -- remember that when you get the record you update // all of it's fields field9 = newdata9; field10 = newdata10; Update MyFile;
    51,365 pointsBadges:
    report
  • TomLiotta
    i can’t get you point clearly You cannot update a record without locking it first. That's a simple fact that you have to program around. However, you can read a record without a lock if you want to display its field values on a screen for a user (or for any other reason). The user can have the record on the screen and go out to lunch. While the values from record are being used by your program, other programs can also use the record. Eventually, the user might either change some values or cancel the display. If cancelled, your program doesn't need to do anything more with that record. It is free to read a different record and display it (or do whatever it's doing with it). But if a change needs to be made, your program must then read the same record again. This time, it must lock the record because this time it will update the record. During the time the record values were on the screen, there was no need to lock the record. The lock only needs to be applied during the small fraction of a second before the program runs the update instruction. So your program must run a second read (with lock!) before the update. If you think about it for a while, this raises an extra problem. But if you really need to avoid conflicts between two users or between two programs, then you must use locking reads before your updates. Tom
    125,585 pointsBadges:
    report
  • pdsathishkumar
    Thanks Mr. Phil and Tom, for your brief explanation. but till now i didn't get the solution..
     C                   if        *in05=*on   
     C     empno         chain(n)  emp         
     C                   update    emp         
     C                   exfmt     help1       
     C                   endif                 
    on my screen, if user ll press the F5 function key, update ll performed. but this code ll shown same error.... can i do any changes from my coding...
    3,790 pointsBadges:
    report
  • philpl1jb
    Beforfe updates and deletes chain to the record without the (N) no lock C if *in05=*on C empno chain emp C if %found( emp) C update emp C endif C exfmt help1 C endif
    51,365 pointsBadges:
    report
  • TomLiotta
    ...if user ll press the F5 function key,... Your code doesn't show how the user presses F5. I assume that your program CHAINs to the record and shows it to the user. The user may change some values and press F5. This gets us to the code that you posted. In that code you have CHAIN(N), followed by UPDATE. But you need to remove "(N)" from that CHAIN because it needs to lock the record. The first CHAIN was only used to display the record. But that second CHAIN has to prepare for the UPDATE that follows. Use "(N)" on the first one, but not the second one. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Right but this cannot work either .. after the sucessfull chain you need to move the changed fields to the data file files then update.
    51,365 pointsBadges:
    report
  • philpl1jb
    changed fields to the data file fiields then update. little typo
    51,365 pointsBadges:
    report
  • TomLiotta
    Right but this cannot work either .. Yep. That's the "extra problem" that I mentioned earlier. I figured that that would be found by the OP once the dual-CHAIN concept started to become clear. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    ...or more thoroughly, that's part of the "extra problem". Tom
    125,585 pointsBadges:
    report
  • pdsathishkumar
    Hi Phil, i used your tips... but it doesn't show any error.. as well as it doesn't update..
     C                   if        *in05=*on               
     C     empno         chain     emp                     
     C                   if        %found(employee)                      
     C                   update    emp                     
     C                   exfmt     help1 -> window name for user display                  
     C                   endif                             
     C                   endif                             
    3,790 pointsBadges:
    report
  • pdsathishkumar
    Use “(N)” on the first one, but not the second one. Hi Tom, after i followed you.
    C                   if        *in05=*on       
    C     empno         chain(n)  emp             
    C                   if        %found(employee)
    C     empno         chain     emp             
    C                   update    emp             
    C                   exfmt     help1           
    C                   endif                     
    C                   endif                     
    it doesn’t show any error and doesn't update.. can i do any change.... please give me any suggestion..
    3,790 pointsBadges:
    report
  • philpl1jb
    For this solution and also as a general good rule, the fields on the display file should not have the same names as the fields from the physical file. As you load each row of the physical file into the display you need to populate each field of the display file from a field of the physical file. On the update routine after you've chained to the physical file you need to move the fields from the display to the physical file record, then update it. Phil
    51,365 pointsBadges:
    report
  • YuVa47
    In simple words, before the update statement you have to move the screen fields to the record's fields as Phil already told you.
    C                   if        *in05=*on
    C     empno         chain(n)  emp
    C                   eval         record.field = screen.field
    C                   update    emp
    C                   exfmt     help1
     C                   endif                
    
    I hope it helps YuVa
    1,300 pointsBadges:
    report
  • YuVa47
    the chain should be without the (n) Sorry :)
    1,300 pointsBadges:
    report
  • TomLiotta
    it doesn’t show any error and doesn’t update.. At this point, how many CHAINs are in your program? You show two of them in the piece of code that you posted. In this code, it looks like you should have another CHAIN somewhere else in your program that we can't see. Your user shouldn't press F5 until after you CHAIN to a record and display it on the screen. Where is that CHAIN? You now show two CHAINs here. The first CHAIN should not be there. It should be somewhere else in your program before you display the screen to the user. That will be where the "(N)" would be used. After the user sees that record and types new data, the user presses F5. Then you can CHAIN without "(N)", and then you can UPDATE. But here's where the "extra problem" comes. The second CHAIN is going to bring values from the database file back into your program. If the user changed any values in the record from the first CHAIN, the second CHAIN is going to wipe out those changes. The UPDATE will just write the data from the second CHAIN back out to the record. The user's changes will be lost unless you put the values from the screen into other variables in the program. (If the fields in the display file have different names from the database file, then those fields will be safe from the second CHAIN.) So, after the second CHAIN, you need to move the values into the database record fields. Then when you UPDATE, the new values will get put out to the database file. When you understand that part of the problem, we'll cover the rest of the problem. Tom
    125,585 pointsBadges:
    report
  • pdsathishkumar
    Hi Phil and Tom, i didn't have different field for database and display file... just i map the database file field in display file.. so the both file (database & display) had same field only... field name in both database and display file EMPNO, EMPNAME, SALARY, etc, like this.... you need to move the fields from the display to the physical file record, then update it. then, how can i move the field value... please give a suggestion...
    3,790 pointsBadges:
    report
  • TomLiotta
    ...how can i move the field value… If you use the same names for the database and display files, you can't move values between the fields because the program uses the same memory for both. You can use the same names when you want the values to be the same in many programs. But if you read a record from the database file after reading the record from the display filewhen using the same names, the values from the display file will be lost. So you need to use different names in an update program like the one you are writing. With different names, you move values back and forth whenever you decide is the right time. Tom
    125,585 pointsBadges:
    report
  • pdsathishkumar
    Thanks Tom and Phil, i got clear solution for this situation. i changed my field name in display file. so multiple user program must contain different field name in database file and display file. now it ll working fine....
    3,790 pointsBadges:
    report
  • TomLiotta
    i got clear solution for this situation. Not quite yet. There is still one problem that needs to be resolved. This problem is maybe the biggest reason that many programmers do not use two CHAINs to perform one UPDATE. They will use a single CHAIN that locks the row the entire time that the user has the record on the screen. Here's the problem: User #1 asks for a record, and your program CHAINs without lock and displays the record. Then, User #2 asks for the same record, and again your program CHAINs without lock and displays the record. The same record is now on two screens at the same time. User #2 makes a change and presses F5. Your program CHAINs with lock and UPDATEs the record. What does User #1 have on the screen? When User #1 presses F5, what record will be retrieved when your program does the CHAIN? And when your program does the UPDATE for User #1, what happens to the change that was made by User #2? Does either user know that the other user made any changes? Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Tom's right about detecting changes by other users or programs. Generally the screen fields have different names from the database fields regardless of update method. Typically when the user requests an update, the data must be validated before the file is updated. Phil
    51,365 pointsBadges:
    report
  • pdsathishkumar
    Tom, your correct. but i don't know how to solve this problem. after i tried use CHAIN without lock (n).. it show same error.
    3,790 pointsBadges:
    report
  • philpl1jb
    Tom, your correct. but i don’t know how to solve this problem. after i tried use CHAIN without lock (n).. it show same error. I'm not sure what you did..solving this probelm shouldn't have required any changes to the code only additions.. When you acquire the row the first time you need to save a copy of a field, fields or more likely the entire record as a data structure. Then when you go into the update routine and acquire the record for a second time you need to compare the orginal with the new values, if they aren't the same, the record was changed by someone else during the time you were viewing it.
    51,365 pointsBadges:
    report
  • TomLiotta
    i don’t know how to solve this problem. There are at least two ways to solve it. The first is as Phil described. Have a DS that your CHAINs load the fields into. Save a copy of the entire DS and compare it against the DS that you get with the second CHAIN. Any difference tells your program that the record has changed since the user first saw it. The second way might be to CHAIN with lock both times. Immediately after the first CHAIN do an UPDATE that sets a flag in the record that says the record is in use. That first UPDATE will release the lock, but any other program that reads the record can test the flag to see if it is in use for updating. The record will be retrieved, but your logic will have to ensure that no changes are made until the record can be safely read. Whatever way you decide to handle it, your program will need to do the testing and to notify the user about the problem. The user will need to choose to wait or to see the changed record or whatever. As I mentioned earlier, this is why many programs don't handle the situation at all. The programs use a single CHAIN with lock and leave the record locked the entire time... because it's easier. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Adding an in-use flag to the file, presents other problems. If the user updates the record the program sets the flag off. If the user moves to another record or exits the screen the program sets the flag off. But if the user is disconnected (closes the session) the flag is left in On status and the row will be in-use forever. To correct that I put the Job# of the locking job in the "flag" field. when a program found the field populated it checked to see if that was an active job. If it wasn't active the record was considered as available for use. Phil
    51,365 pointsBadges:
    report
  • pdsathishkumar
    [...] 1. Pdsathiskum, Philpl1jb, TomLiotta try to solve the error when updating the PF using a RPGLE program. [...]
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following