Re: Program design to minimize record locks

Notice there is only one data structure. The other two fields are just chunks of space. As to pushing your RPG skills, I'm suspecting that after you do it and then look back at it you'll say something like "Huh? That was simpler than I thought!" :)

To answer your questions:
1-Shouldn't be.
2-Yes

I believe you have it all in your head excepting one small piece. Your thinking is correct excepting that since the two holding fields are fields, not data structures, there is no conflict. The FileNameDS does in fact always have the most recently read data values, whether from the original read(n), the screen exfmt, or the locking read. You need to be able to count on that fact to make the process work.


Pete Helgren wrote:

Thanks Booth. You had weighed in in a similar manner a while back (I just found the thread).

This will be pushing the envelope on my RPG skills a bit (and my understanding about how RPG works). Let me make sure I understand. If I use the technique you identify, then I won't have any issues with the screen field references or other references in the program correct?. Your only concern is that the D specs might have to be added to the individual source members? That may be OK.

A few follow up questions to make sure I am thinking clearly:

1. Will there be a problem if there is a F spec that does an initial RENAME on the file? e.g
FMYFILE UF A E K DISK RENAME(MYFILE:FILE01) This is used since the FILE01 reference is in the /Copy member

2. I haven't worked with DS's much, so when you say "move" is it as easy as setting OrigData = FileNameDS? That is, treating the DS as a single variable? The comparison of the DS is likewise done on a "single variable" basis? If so, that is pretty simple.

I am trying to figure out how the program is keeping track of the different fields if the names are the same in all the data structures and how the data in the screen format also "knows" what field to map to in the data structures.

For example (VERY simplified):

My "classic" approach in my interactive programs is to have data fields in the file match the data field names on the screen. So if I have field1 and field2 in the file and field1 and field2 on the screen, when I read the screen and write to the file the data from the screen goes to the file. How does this work when I have one instance of the field on the screen and three instances in data structures? I am having difficulty getting my head around that.

For example if you have file1 with field1 and field 2 and then 2 DS's based on file1 that would presumably be three instances of the same fields. When I read the screen format that also has field1 and field2 defined, how do I know where to map the data from the screen to the DS? Are the screen format fields always mapped into the file format fields?

I just want to be clear because then your solution would be very simple to implement. Psuedo code:

1. READ(n) file01 (which is mapped into FileNameDS)
2. move the FileNameDS into OrigData (presumably by just setting OrigData = FileNameDS)
3. Do screen stuff, edit and read screen format (which puts it back into FileNameDS ? I am not sure about this)
4. move the FileNameDS into NewData (presumably by just setting NewData = FileNameDS)
5. read(with lock) File01 again (which maps the data into FileNameDS)
6. compare FileNameDS to OrigData (presumably by using direct compare operands, DS to DS)
7. If not equal raise an error
8. If equal then move NewData into FileNameDS (which maps the data back into File01)
9. Update File01

If my assumptions are correct, I'll give this a whirl.

Pete



Booth Martin wrote:

What has worked for me in the past is to define a data structure with the EXTNAME() keyword and then two fields LIKE() the data structure.
Something like this:

D FileNameDS ds extname(Filename)
D OrigData s like(FileNameDS)
D NewData s like(FileNameDS)

Then read(n) the data, move it into OrigData and present the screen.
Do your stuff.
Then if ready to write, move FileNameDS into NewData and read(locking) again.
if FileNameDS <> OrigData the record has been changed elsewhere; otherwise, move NewData into FileNameDS and update the data file.

I am not sure how is the easiest way for you to get the definion specs into each program however.
Pete Helgren wrote:

I have a change I need to make to a program that someone else had written. The program logic for data I/O is in a /Copy member so that all programs using the logic are affected by a current "design flaw" in the program which READs the record and locks it until the screen is exited and the record is updated. The record lock causes problems elsewhere.

So, without making too many changes and breaking something, I figure I should be able to:

1. READ the record (with no lock)
2. Present the data to the screen
3. Edit the data as usual
4. READ the record again with lock for update
5. Update the record releasing the lock.

This is standard stuff, but I think I need a "intermediate" storage step to hold the initially read record, yes? All of the RPG programs I have had experience with in the past have "direct" read/write IO with file record fields mapping to screen data fields using identical names. In this revision, I think I can't do that since the second read of data would overlay existing fields with the same name. So, I think I need to use a data structure to temporarily hold the original data while it is edited and verified.

So, what is the simplest approach to reading the data file record, moving it into a DS, and then moving it out of the DS and back into the data file after being re-read? And yes, I know that I'd have to check to make sure the record hadn't been updated during the time it was originally read and later updated. I poked around for some examples last night and couldn't find anything I could use (immediately). I'd like to avoid having to go back to each program that uses this /Copy member to make changes. I'd like to only change the /Copy member if possible.

Am I making any sense? Ideas?

Thanks,

Pete