RE: Advice needed on a multimember DDS file to be converted to DDL

If you added the MEMBER field as you suggest, then the CL overrides,
instead of being to MBR(), simply restrict to MEMBER=something. You
would need to recompile the RPG programs due to the added field, but if
they don't "do anything" with members today, why would they tomorrow?

How do orders go from one member to another? Now THAT program would have
the biggest change.

No real reason to use SQL here, although you can do something like
With temp as (select fields from orhdr where member=blah) etc.
...which effectively performs the same task as OVRDBF.

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 Jeff Crosby
Sent: Friday, April 25, 2008 11:55 AM
To: Midrange Systems Technical Discussion
Subject: Advice needed on a multimember DDS file to be converted to DDL

As I have noted at least once before, I have gone through and converted
over 360 DDS defined PF to be DDL defined. Plus all the associated LF
to Indexes/Views. I am now doen to the last 2 PF, the order header and
order detail (ORHDR and ORDTL, respectively). I saved these for last
because they would be the hardest.

They are both multimember and have associated LF, also multimember.
There are 2 permanent members, 1 for current days orders and 1 for
advance orders. There are also hundreds of transient members
added/removed daily, normally removed within seconds of being added.
What happens is the sales people (called a DSR in the business)
transmits an order from their laptop, a unique member is added to the
files, the order gets placed into that member, gets processed, and the
results transmitted back to the DSR immediately. By putting each of
these orders into it's own member, it is kept logically separate. After

the results are transmitted to the DSR, the order gets moved to the
advance order member and the transient member is removed. There are no
performance issues whatsoever with this approach.

There are 66 (!) RPG programs that touch one or both of these files. A
CL wrapper with OVRDBF is what points RPG to the correct member. Many
of these CLs also have OPNQRYF in them. I am hitting my head against
the wall trying to come up with an elegant way to do all this. 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.