Ha, my bad on the bit about Output not caring about renamed field length. It wasn't creating the =O specs in my program b/c I removed the procedure. I put the procedure back in and of course it created the =O specs and then ran into the field name length issue.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson
Sent: Thursday, August 12, 2010 9:41 AM
To: 'RPG programming on the IBM i / System i'
Subject: RE: RPG File Input/Output Specs
I really couldn't go the program-defined route. Wasn't obvious in my shortened example, but I'm doing an eval-corr then individually converting the fields that eval-corr wouldn't accommodate.
I went the route of using PREFIX('OLD.') and PREFIX('NEW.'). Kind of a bugger that there's a field name length limitation in doing this. Although (for some good reason I'm sure) this name length limitation only seemed to apply to the input file, not to the output file.
We're soooo close to 6.1, too. Would have been really nice to simply qualify the files.
Thank you both Stuart & Barbara for the feedback. Barbara a special thanks for input on how the compiler works.
-Kurt
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Wednesday, August 11, 2010 5:59 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: RPG File Input/Output Specs
Kurt Anderson wrote:
...
But once I introduce a procedure into the program, it creates the
=O specs for NewFile, which then causes a conflict because some
fields share names between the files, but do not share the same
definitions.
Is there a reason for this? All I know to do is to change the
procedure to be a subroutine (shudder) and continue on my way.
...
The RPG compiler is a one-pass compiler, which means that it only reads
the source once. It creates the listing and generates the =O specs
while it's reading the source.
When it sees the first P spec, it has to generate all the =O specs so
that they will be available in case one of the later procedures is going
to do a WRITE or an UPDATE opcode.
One way to get around this would be to code PREFIX on the F spec for
NewFile, say PREFIX(N). That will cause the O specs to get different
names. If that might cause a new conflict, you could code PREFIX('N.')
and define a qualified data structure N with LIKEREC(NewFileF:*OUTPUT).
Aside: I see you're on V5R4, but if you were on V6R1, you could code
QUALIFIED on the F spec for NewFile, and you won't get any =O specs
generated.
Then you'd have to qualify the record format:
Write NewFile.CdrMstF ds_New;
midrange.com
