Re: Treat file fields as an array

Another option would be to do what Mark suggested but with a VIEW.

Create view customer_addresses (address_type char(10), customer dec(6,0),
address char(30), name(char 30) as (
select 'BILLTO' as address_type, btcustomer, btaddress, btname from
custfile
union all
select 'SHIPTO' as address_type, btcustomer, btaddress, btname from
custfile
)

Select * from customer_addresses where address_type = 'BILLTO'





On Wed, Mar 12, 2014 at 8:31 AM, Michael Schutte <mschutte369@xxxxxxxxx>wrote:

Ten addresses in the file? I appears to me that you want to read a record
and have them put into an array. So...

D DS
D BTCustomer
D STCustomer
D Customers 1 12S 0 Dim(2)

D DS
D BTAddress
D STAddress
D Addresses 1 60 Dim(2)
D DS
D BTName
D STName
D Names 1 60 Dim(2)

Customers gets defined as a 6,0 signed array.
CUSTOMERS(2) S(6,0)

Addresses as a 30 character alpha array.
ADDRESSES(2) A(30)

And the same for Names.

As you read(chain to) a record, theses arrays are automatically populated.

Just add the other 8 addresses to the DS, increase the size of the array
and the number of elements.

I would also create constants that would tell me what each array element
was.

D BillTo C 1
D ShipTo C 2
etc


Normalizing the data would be ideal but in reality is more complicated.



On Tue, Mar 11, 2014 at 4:55 PM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Charles:

Why not "fix" the "real" problem and "normalize" the database? =-O

Mark S. Waterbury

> On 3/3/2014 1:47 PM, Charles Wilt wrote:

Soctt,

Yes I was simplifying the example. In reality I'm dealing with a set

of 10

fields...

Your example of
D CustAddr_t ds qualified template
D Customer like(BTCustomer)
D Name like(BTName)
D Address1 like(BTAddress1)

D Addresses ds
D BTCustomer
D BTName
D BTAddress1
D STCustomer
D STName
D STAddress1
D Cust likeds(CustAddr_t) Dim(2)
D overlay(Addresses:1)

Is what I was thinking about...

I'm not currently using DS I/O but I could switch too it without issue.

I shouldn't have to worry about the BT/ST not matching.

I just really didn't like the look of duplicating 15 lines of code (10
evals and say 5 for chain) and was hoping there was a better way.

But 30 lines of code vs. 20+ lines of D-specs...perhaps not worth the
"trickyness" :)

Charles


On Mon, Mar 3, 2014 at 1:27 PM, Scott Klement <

rpg400-l@xxxxxxxxxxxxxxxx>wrote:

Hmmm... maybe that's it. Maybe there's a lot more addresses, and each
one has more fields, etc. And he was just simplifying it for the sake
of the post.


On 3/3/2014 12:21 PM, Briggs, Trevor (TBriggs2) wrote:

Yes, you're right. It just seems like a lot of trouble to go to avoid

a

few Evals. I would find the Evals much easier to understand if I was

the

person who had to amend this program in 5 years time. If there were 10
sets of address fields, then fair enough, but for two?

--
This is the RPG programming on the IBM i (AS/400 and 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 IBM i (AS/400 and 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.