Re: Subfile Processing -- RPG400-L

When the user edits one of the displayed subfile records and hits enter I
attempt to save it back to the correct file using a DOW to loop through
each record returned from the subfile using READC(E) until I get an %EOF.

Why (E)? Why not just READC? Seems to me that if something goes wrong,you want to know about it.

In this loop I use a KLIST to search using SETLL(E) on the physical file
to find the corresponding entry to the subfile entry I'm working on.  If I
get an %EQUAL result then I know it's an update to an existing record in
the physical file so I use UPDATE(E) to write it out.  Otherwise I use
WRITE(E) to write the new record.


Same comment about (E).

You have to read a record before you can update it. So you need to CHAINto that record, or use a READE after the SETLL (making sure that you getthe same record) and then you can change the fields and issue an update.

Normally, if you didn't READ prior to the UPDATE, you'd get an errormessage, but since you have (E) on the UPDATE opcode, you're telling it tocompletely ignore the errors, so you don't even know why it failed.

Frankly, putting (E) on everything isn't a good idea. Only use (E) whenyou're expecting an error and your program knows how to handle it. Andmake darned sure that you check %error so that you know whether theoperation succeeded or failed.

Otherwise, leave the (E) off, and use a *PSSR to dump the job log ande-mail it to you if something fails. That way, unexpected errors willdefault to notifying you and providing you details instead of justcontinuing the program with nobody understanding that something wentwrong.


This all works fine for the case of adding a new record, but when I go to
update an existing one the changes don't make it back to the physical
file.  Any ideas?

(as I said above) it's because you're not reading the record beforeupdating.