MEMBER would be an index field or a key field, but does it have to be
primary key? After all, unless Jeff allows duplicate order numbers, the
underlying RPG programs would remain the same. Isn't overriding to the
member TRANSIENT1 the same as overriding to the set of records where
MEMBER=TRANSIENT1?
In other words, since the underlying RPG programs don't know or care
which member they process today, moving from a member name to a field
value should not cause a problem. The RPG cares about customer/order
combinations, not member/customer/order.
Since all the data eventually ends up in one of two permanent members
anyway, Jeff wouldn't have duplicate order numbers or somesuch.
To me, the more involved piece are the programs that move orders between
members.
It sounds straight-forward from here. Perhaps there's a wrinkle I don't
see?
Loyd Goodbar
Business Systems
BorgWarner Shared Services
662-473-5713
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Friday, April 25, 2008 1:01 PM
To: Midrange Systems Technical Discussion
Subject: RE: Advice needed on a multimember DDS file to be converted to
DDL
Jeff Crosby wrote:
I'm sure I have to add a MEMBER field to the files.
But I'm trying to find a way that I don't have to rewrite
it all.
I don't know of a way of adding MEMBER as a key field, and not
significantly disrupting existing programs. It sounds like you have a
valid reason for using multi-member files, so my initial thought would
be to continue using them.
Nathan.
midrange.com
