Thanks again Scott. Yes, you probably missed the first part of this but
I think we are sorting through it. To you and all who weighed in on this
so far, here is where I am (still stuck).
Quick reminder snippet:
The existing program is using a /Copy member for I/O. My hope was that
changes to the /Copy member containing I/O should NOT require changes to
the screen DDS and should have minimal impact on existing programs. For
example: If the solution involves having to go back into all the DDS
source to make changes and all the RPGLE source to make changes then
I'll do it, but only as a last resort. I am trying to minimize rework
to all the other RPG source members. So on to your recommendations:
a) Extname - Causes a RNF3804 error on the fields that are in the screen
format that have the same name as the data structure or file (I
think...the error is pretty vague:"Name Field1 in external description
PMYFile is not renamed external name is ignored.")
b) Use likerec and read into the the data structure. Question here is
that I am relying on the "automatic" mapping of data from the screen
into the record for I/O. Booth's solution has the data mapping into the
DS wherever there is a file READ. No need to Read it into the DS
because that part is "automatic" the DS has the data as the file is read
(or so I understand).
c) If I add a prefix then I'll have to change more code to add the
prefix to fields explicitly, correct?
So let me give you some examples and see if I can sort all this out.
First the "simple" approach:
File PMYFILE had two fields, CUSTNO and CITY.
Screen format FORMAT1 has two fields CUSTNO and CITY.
In this case I:
1. Read PMYFILE
2. Write to FORMAT1.
3. Change screen data
4. Read FORMAT1
5. Update the file.
Simple. The only problem is that between the READ and the UPDATE on
PMyFile, the record is locked. No good.
Booths "minimal lock" approach is to read PMYFILE which automatically
maps the data into the DS (with extname) and it is also automatically
available to the screen format. So I would have (theoretically):
1. Read PMYFILE (also populates FileNameDS) with no lock.
2. Save FileNameDS into OrigData
3. Write to FORMAT1
4. Change screen data
5. Read FORMAT1 (also populates FileNameDS, correct?)
6. Save FileNameDS in NewData
7. Read PMYFILE again (which reloads FileNameDS)
8. Compare FileNameDS to OrigData Take action if something changed
9. Move the NewData back into FileNameDS (which loads PMYFILE)
10. Update the file.
Since I can't get the extname option to compile because of the RNF3804
error, I used likerec. I explicitly read the data into the FileNameDS.
So now I have a problem. If someone changes something on the screen I
have to explicitly move the data back into the DS in order to be able to
save it later before I read again, yes?
What I saw after using likerec and reading the data into FileNameDS and
then updating data on the screen and updating the file was no change to
the record at all. I think that was because the screen field (and file
field) CITY is now different than the CITY field in the data
structure. I have a CITY field that the file and screen can
automatically exchange but a data structure that has to be explicitly
read into and from. Using likerec I'll have to change all my rpg
programs to move the data from the screen to the data structure
explicitly whereas before that happened automatically (at least between
screen and file). Adding the DS adds a bunch more coding for me. We are
talking about hundreds of fields and dozens of programs I'd have to
update. I can do this, but one of my objectives was to change the /Copy
routines to have a minimal impact on the overall existing code. But, if
extname won't work and likerec does but requires a bunch of work, I'll
do it.
Your option "c" seems to be just as invasive as using likerec: I'd have
to change a bunch of code to move data between screen, file and data
structure.
Do I have this correct? Again, the idea was to come up with a solution
which would remove the record locking issue while the screen was
displayed but didn't require a wholesale change to all the RPG and DDS.
Pete
Scott Klement wrote:
Hi Pete,
Based on the prior posts from Booth, I thought I understood that the
D spec for the data structure would hold a copy of the data read from
the file "automagically".
There's no magic to it, Pete. When you compile an RPG program that uses
an externally defined file, the compiler reads the file description and
generates input specs that are used under the covers.
The input specs reference the field names in the program that the data
should be read into.
So if (for example) your external definition has fields named CUSTNO,
NAME, CITY, STATE, then the data structure would have fields with those
names, and so would the input specs, since they're both based on the
same file. Consequently (assuming the data structure isn't qualified,
prefixed, etc) it "automagically" reads into the DS.
So either I misunderstood or I am doing something wrong (that
wouldn't surprise me).
You understood perfectly, however, when I recommended LIKEREC, I didn't
realize that this is what you're trying to do. (Perhaps I came into the
middle of the conversation?)
The thing is... LIKEREC automatically qualifies the data structure. So
now your data structure field names are FileNameDS.CUSTNO,
FileNameDS.Name, FileNameDS.ADDR, etc --- and they no longer match the
file names that are CUSTNO, NAME, ADDR becaause they're qualified by a
data structure name.
There are many fixes to the problem, and none of them are difficult.
Here are the fixes that come to mind:
a) Use EXTNAME instead of LIKEREC (though, keep in mind that the EXTNAME
must be based on the external file name)
b) Continue using LIKEREC, but tell the RPG op-codes (READ, CHAIN,
WRITE, etc) to read into a data structure. For example:
chain key file01 FileNameDs;
The 4th parameter to the chain opcode (which is the result field in
fixed-format) contains the DS you want to read into.
c) Use a PREFIX on the F-spec to tell it to add the 'FileNameDs.' prefix
onto the input specs so you don't HAVE to read into the DS.
FPMYFILE UF A E K DISK RENAME(FMYFILE:FILE01)
F PREFIX('FILENAMEDS.')
In this case, it'll generate input specs that read directly into your
DS, since the input specs will read fields name FILENAMEDS.CUSTNO and
FILENAMEDS.NAME instead of simply CUSTNO and NAME. (For example, again)
I'm sure there are additional options that haven't come to mind yet.
But, hey, how many solutions do you need?
midrange.com
