|
OK, I think I've finally got it now (can't say I like it, but I think I understand it...). You're problem is, of course (as you said right at the beginning of all this - doh!) that you can't copy more than one record format at a time from the logical. You _could_ copy each record format from the logical in turn, e.g.: CPYF InvoiceLF TOFILE(PF1Copy) RCDFMT(PF1Record) CRTFILE(*YES)... CPYF InvoiceLF TOFILE(PF2Copy) RCDFMT(PF2Record) CRTFILE(*YES)... CPYF InvoiceLF TOFILE(PF3Copy) RCDFMT(PF3Record) CRTFILE(*YES)... etc. This gives three physical files containing a copy of the contents of the header, detail and totals files. Unless I'm missing something I can't see the advantage of this over copying each physical separately. You can then create a logical over these physicals as somebody else described if you need it. Are these copies just needed for backup or maybe reprint purposes? It's glib and probably annoying of me to say "I wouldn't design it like that" but I can't resist it. I guess this is probably something you've inherited and you're stuck with. That's a situation I can relate to all too well sadly. Pete "John Furniss" <jfurniss@xxxxxxxxxxxxxxxxx> wrote in message news:3EA953CA.F3406208@xxxxxxxxxxxxxxxxxxxx > Thanks for hanging in there with me, Pete. No, InvoiceLF is over the same set of > physical files. I populate all three of them, then I want to copy the LF to > another name, clear these same PFs, populate them, copy the LF, clear, populate, > copy, clear, populate, copy, etc. > > Pete Clifford wrote: > > > Thanks, but, sorry, I just need clarify things a bit further. Are you saying > > that InvoiceLF is recreated over a different set of physical files for each > > invoice? Is that the way it works? The application processes a file called > > InvoiceLF, but each time it's called InvoiceLF is built over a different set > > of physical files specific to the invoice in question? > > > > Or am I still being thick? > > > > Pete > > "John Furniss" <jfurniss@xxxxxxxxxxxxxxxxx> > > wrote in message news:3EA94C39.ADADF342@xxxxxxxxxxxxxxxxxxxx > > > I understand that this scenerio can be/is confusing, and maybe I'm going > > about > > > it all wrong. What is happening is: We will run our custom-built invoicing > > > process, which will populate the header, detail and total PFs which have > > the LF > > > over them. I will then "rename" the logical to the invoice number for this > > > particular invoice. Then the process happens again. Each invoice number > > needs > > > it's own set of header, detail and total files. It would look like this: > > > Header_invoice_123 --- > > > Detail_invoice_123 --- > > > Detail_invoice_123 --- ----> InvoiceLF -----> rename (or copy) to > > File123 > > > Total_invoice_123 ---- > > > > > > Header_invoice_456 ---- > > > Detail_invoice_456 ----- -----> InvoiceLF -----> rename to File456 > > > Total_invoice_456 ----- > > > > > > and so on. > > > > > > Clear as mud? Am I going about this wrong? One main problem is that all > > three > > > PF's have different record lengths. > > > John > > > > > > Pete Clifford wrote: > > > > > > > Not sure what you're trying achieve by all this I'm afraid John. > > > > > > > > You say: > > > > > > > > "I need to copy this LF to another file name, clear the PFs, re-populate > > > > the PFs, copy the LF to another name, etc. The name I'm copying to is > > > > different each time." > > > > > > > > Why do you need to copy the logical? Why can't you just copy the > > > > physical(s)? Is it because the logical is the only one with keys and you > > > > need to copy by key? > > > > > > > > Can you also clarify why you're clearing the physicals and then > > repopulating > > > > them please? > > > > > > > > Any why do you need to copy the LF to another name? > > > > > > > > Sorry, not trying to be obtuse, but rather than launch into what you can > > and > > > > cannot do with a multi-format logical, I think it's important I/we > > > > understand what the basic objectives are here. > > > > > > > > Pete > > > > > > > > "John Furniss" > > <jfurniss@xxxxxxxxxxxxxxxxx> > > > > wrote in message > > news:3EA93F61.5C1C8840@xxxxxxxxxxxxxxxxxxxx > > > > > List, > > > > > I searched the archives, but found nothing to help me with this: I > > > > > have an LF (FileLF) over 3 seperate PFs (FilePF1, FilePF2, FilePF3), > > and > > > > > I need to copy this LF to another file name, clear the PFs, > > re-populate > > > > > the PFs, copy the LF to another name, etc. The name I'm copying to is > > > > > different each time. > > > > > It may seem like a strange setup, but this makes up an invoice > > file > > > > > with three different record lengths (header, detail and total > > records), > > > > > hence the 3 different PFs with one LF over all three. > > > > > When I try to copy the file with it's three members and try to > > > > > create the file, get an error saying I cannot copy a multiple member > > > > > file and do a create at the same time. Can I create a join file for > > all > > > > > three? > > > > > Ideas? > > > > > Thanks in advance, > > > > > > > > > > -- > > > > > John Furniss > > > > > Applications Programmer > > > > > Allied Machine & Engineering Corp. > > > > > mailto:jfurniss@xxxxxxxxxxxxxxxxx > > > > > Phone (330) 343-4283 ext. 8371 > > > > > > > > > > > > > > > _______________________________________________ > > > > > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing > > list > > > > > To post a message email: > > RPG400-L@xxxxxxxxxxxx > > > > > To subscribe, unsubscribe, or change list options, > > > > > visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l > > > > > or email: RPG400-L-request@xxxxxxxxxxxx > > > > > Before posting, please take a moment to review the archives > > > > > at http://archive.midrange.com/rpg400-l. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing > > list > > > > To post a message email: > > RPG400-L@xxxxxxxxxxxx > > > > To subscribe, unsubscribe, or change list options, > > > > visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l > > > > or email: RPG400-L-request@xxxxxxxxxxxx > > > > Before posting, please take a moment to review the archives > > > > at http://archive.midrange.com/rpg400-l. > > > > > > -- > > > John Furniss > > > Applications Programmer > > > Allied Machine & Engineering Corp. > > > mailto:jfurniss@xxxxxxxxxxxxxxxxx > > > Phone (330) 343-4283 ext. 8371 > > > > > > > > > _______________________________________________ > > > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > > > To post a message email: RPG400-L@xxxxxxxxxxxx > > > To subscribe, unsubscribe, or change list options, > > > visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l > > > or email: RPG400-L-request@xxxxxxxxxxxx > > > Before posting, please take a moment to review the archives > > > at http://archive.midrange.com/rpg400-l. > > > > > > > > > > _______________________________________________ > > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > > To post a message email: RPG400-L@xxxxxxxxxxxx > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l > > or email: RPG400-L-request@xxxxxxxxxxxx > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/rpg400-l. > > -- > John Furniss > Applications Programmer > Allied Machine & Engineering Corp. > mailto:jfurniss@xxxxxxxxxxxxxxxxx > Phone (330) 343-4283 ext. 8371 > > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo.cgi/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > >
As an Amazon Associate we earn from qualifying purchases.
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.