What about extracting the subset to a file in QTEMP? Let the users manipulate the data there and then move it back to production. That would only work for the job though. If work goes over a multiple sessions it won't work.
If the members are needed between sessions maybe creating your own 'temp' library would work. It will require some overrides to get the correct files when copying out of and into production.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of JK
Sent: Friday, July 11, 2008 6:38 PM
Subject: Modernization and multi-member files
As part of a modernization effort, I'm trying to move our RPG system away from DDS-specific functions but am having difficulty finding anything in SQL that provides the simplicity and elegance of multi-member files and RPG's
We have an application that allows users to extract a subset of order-entry data (ORDER_HDR, ORDER_DTL, etc.) into uniquely-named members. Once cloned, users are able to manipulate their temporary copy of the data as necessary, running 'what-if' scenarios, etc. in their own private sandbox without affecting the production data. When finished with a batch, the user can save their work in the temp member, append it production, jump to another member, etc. Since the members are in the same files they all share record formats, indexes, RPGs, queries, *AUTLs and journals. Nice and tidy.
If this app is switched to SQL we'll have to abandon the multi-member concept and I'm having difficulty visualizing the 'SQL way'. Partitioned tables aren't appropriate in this case because the separation really isn't based on a range or hash. Creating temporary libraries brings up its own set of issues with *LIBL and security.
I suppose one could design a system with two sets of tables
(ORDER_HDR/ORDER_DTL) and (ORDER_HDR_T/OREDR_DTL_T), prefixing each row with a key (a.k.a. "member") that each program would filter on. It seems like extra overhead, but maybe that's because I'm looking at things from a DDS perspective.
For future reference, perhaps some of you SQL folk would be kind enough to offer suggestions about how you would tackle something like this.
Many thanks, JK
Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.