× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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;

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.