Don';t know why clean up would be any harder with savefiles Darryl thee are still library band objects so you would simply use WRKLIBPDM instead of WRKMBRPDM no big difference. Admittedly you'd have to restore to run a query but how often doe that happen? Personally I just dislike multi-member files so much I'd do most anything to avoid them!

All of the WRKxxPDM commands have equivalence in RDi - particularly in the latest version with the PDM interface.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jan 17, 2019, at 3:55 PM, a4g atl <a4ginatl2@xxxxxxxxx> wrote:

My objection to using SAVF's is, it becomes a management nightmare with 30
or 60 days of files. Part of my process is to clean up older members which
I could not do with SAVF's but...

The advantage of the members has been that I use WRKMBRPDM file_name and I
see all the members. I can then use the option codes defined in F16 to give
me commands to manage the members. Example: RR - RUNQRY *N file_name
member_Name RCDSLT(*YES). Other commands I have are to resend the member
when its not received or a resend is requested.

Quite frankly, WRKMBRPDM was a great tool that does not have a replacement.

Darryl Freinkel
Assignment 400.


On Thu, Jan 17, 2019 at 12:58 PM Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 1/17/2019 8:13 AM, a4g atl wrote:
I have a situation where I have a table defined. In the past I used PFs.
The table has a long and short name. This prevents me from using CPYF or
CRTDUPOBJ. I have used RUNSQL to do a Create Table ... as (select..)
with
no data. This creates a table not a PF, okay.

I need a PF with Multiple members that is identical to the table. I use
the
member to store copies of file we send to external systems as an archive.
The member functionality has been great for this and I do not want to
have
hundreds of files in the library.

No lecture from me; this is a hard transition when the code base expects
multiple members. Do you already have an inquiry program that knows how
to switch members? When possible here, I've really, really advocated to
re-do that architecture to put the year (or whatever each member is
intended to segregate) into the archive table. So instead of (simplified):
ID
NAME
ADDRESS
SALES

I have:
YEAR
ID
NAME
ADDRESS
SALES

Extracting one 'member' of data is as easy as WHERE YEAR = :year;
comparing two arbitrary years is just as easy. Quite to do ugly with
multiple members.

To answer your actual question, search the web for RTVDDSSRC. Michael
Sansoterra posted a utility many years ago that will probably do what
you need: create DDS from DSPFD / DSPFFD.

--
--buck

http://wiki.midrange.com
Your updates make it better!

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.