RE: Cycleing - Multiple Input Files

Nothing bad with FRR indicators. A tool is only as good as its user.
For programs that use variable length input they can help overcome
the overflow problem (forgot the message) where the program defined
input specs greatly exceed the length of the actual records.
Needed to process data from journal files where the record length
could be anything. Tried to do it with SQL with PREPARE but that
failed as the pre-compiler constructs code based on a actual
file it finds at comile time. Perhaps there is a way to do this
with SQL but it sure beats me. (DESCRIBE? ) I dont know how or
why to use Describe.
BUT I did solve my problem with Program Described File and FFR ind.

Frank

In my entire 30+ years I've only used field relation indicators once.
In fact, that's the only program I've ever seen them used in.
I wouldn't wish that on my worst enemy (well, maybe him).

Jerry C. Adams
IBM System i Programmer/Analyst
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx

-----Original Message-----
From: Frank.Kolmann
Sent: Thursday, August 21, 2008 6:15 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Cycleing - Multiple Input Files

Weeell since you mention RPG II, if you had a record ID field
that allowed you to distinguish between the 2 records you could
have Program Described input fields and use the Field Record Relation
indicator column.
Did a lot of stuff in RPGII with variable record layouts
and Program Described files before normalised files became the fashion.
No need for external switches etc. etc.