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

[Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>]

Agreed on the changing MEMBER field.  I envisioned that program 
utilizing an SQL statement like

update <file> set member = <newmembername> where member = <oldmembername>

lgoodbar@xxxxxxxxxxxxxx wrote:
> 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.
>
>
>