Hi Trevor,
On 3/3/2014 11:38 AM, Briggs, Trevor (TBriggs2) wrote:
Scott, my reading of the question is that the OP wants a way to define
the addresses in such a way that he can process them as an array without
doing those 6 evals, and off the top of my head, I don't think he can.
I'm still not 100% sure that I understand. But, he could do something
like this, right? (This assumes that he's not using DS I/O):
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)
Of course, this trades 6 eval statements for 14 lines of DS definitions.
Not sure that it's worth it?! Also, if the BT fields are ever changed
to a different length than the ST fields, the overlay won't work
properly, and will cause problems here that will not produce a compiler
warning or error. Still.. it'd work, right?
If he is using DS I/O, then he could do it with pointers:
D CustAddr_t ds qualified template
D Customer like(BTCustomer)
D Name like(BTName)
D Address1 like(BTAddress1)
D Cust ds likeds(CustAddr_t) dim(2)
D based(p_Cust)
D p_Cust s * inz(%addr(BTCustomer))
This would only work if the address fields are all together and in the
proper sequence, and it also would have the same problem as the first
solution if the BT/ST fields ever didn't match.
But, would work.
But, at the end of Charles' original message, he shows something like this:
Cust(1) = GetCustinfo(wBtCustomer);
Cust(2) = GetCustInfo(wStCustomer);
//eval-corr here perhaps?
So that makes me think that he didn't really want to make the database
read automatically load stuff into the array, but that he wanted to do
it with eval-type opcodes... But, it's hard to see how this would
save him much vs. just eval the 6 fields...
Hopefully he can clarify.
midrange.com
