Re: Program design to minimize record locks

On the other hand, you could have the save fields be like the screen data structure too and they would be automatically filled, too, if the screen field names were the same as the physical file(s)? In other words, I could easily process data from more than one data file without any field moves in the calcs?

This has interesting possibilities.... hmmmmm...



Francis Lapeyre wrote:

True, but I'd prefer to base the data stucture on the external file instead
of the display file, because then I can just compare the data structures to
see if they are the same or not before I do the update (the data structures
for the screen field typically will have a PREFIX keyword to distinguish
them from the PF fields).

Francis Lapeyre


On 7/20/07, Gene Burns <burns.gene@xxxxxxxxx> wrote:

You can have an externally described DS for screen fields just as you can
for DB files. The following will give you a DS with all the input capable
fields on the display format selected.

d screenDS e ds extname(DisplayFile: RecFormat:
*input)



On 7/20/07, AGlauser@xxxxxxxxxxxx <AGlauser@xxxxxxxxxxxx> wrote:

Scott Klement wrote on 19/07/2007 18:35:07:

[...]
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:
[...]
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)

Pete, if you use b) or c) you will also have to take steps to get the
fields from the screen in to the fileNameDS structure, as I don't think
you can use qualified names in the DDS specs for the screen. You could
make a DS with all your screen fields (following Scott's example):

D screenFields DS
D scCustNo like(fileNameDS.custNo)
D scName like(fileNameDS.name)
D scAddr like(fileNameDS.addr)

Then, you use the sc* fields in your DDS, and use fieldNameDS =
screenFields after you READ or EXECUTE your DDS record format. That

said,

it seems it would be much simpler to use EXTNAME as Booth suggested

(using

the actual name of the PF) unless the actual name is not known at

compile

time.

Hope this helps,
Adam

Attention:

The information contained in this message and or attachments is
intended only for the person or entity to which it is addressed and may
contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this
information by persons or entities other than the intended recipient is
prohibited. If you received this message in error, please contact the
sender and
delete the material from any system and destroy any copies. Thank you

for

your
time and consideration.

Attention:

Le contenu de ce message et(ou) les fichiers ci-joints s'adressent
exclusivement à la personne ou -entité à laquelle ils sont destinés. Ils
peuvent
contenir de l'information confidentielle, protégée et(ou) classifiée. Il
est
strictement interdit à toute personne ou entité autre que le(la)
destinataire
prévu(e) de ce message d'examiner, de réviser, de retransmettre ou de
diffuser
cette information, de prendre une quelconque action en fonction ou sur

la

base
de celle-ci, ou d'en faire tout autre usage. Si vous avez reçu ce

message

par
erreur, veuillez communiquer avec l'expéditeur(trice), supprimer ce
message et
les fichiers ci-inclus de tout système, et en détruire toutes copies,
qu'elles
soient électroniques ou imprimées. Nous vous remercions de votre entière
collaboration.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.