|
It seems that some people get a real case of the ebee-jebee's at the sight or mere mention of MR or the RPG cycle. (The willies you never really recover from) ;-) I'll like to mention (with tongue planted firmly in cheek) that I think that if that's what you claim to feel, yet USE them you're keeping some of the best stuff for yourselves. Now I'm not saying to use them everywhere, but I would like to present a case where MR is a handy maintenance program solution. Example: You have a master file with several auxilary files of information, let's say a customer master file with a unique keyed logical by customer number and a notes file with a unique key logical by customer number, date and entry number. While editing notes, you choose to delete a note. As a standard course of action we mark the entry for deletion so we can provide an undelete function. While editing the customer master file we also just mark the master for deletion. We do not mark all dependant children files records for deletion. That gets done later. This way we can undelete the customer master without having to undelete the dependants, not knowing which were intentionally deleted as above. This is a function of a periodic housekeeping program which uses the customer master keyed logical as the IP file, and the customer notes keyed logical as the IS file and a shared access path duplicate of the notes keyed logical as a UF file. We do it this way because if we ran the notes file as US we would be locking each an every record that we came accross, not good. The program looks something like this (free style typing, but I think you'll get the point) (BTW how can I get my Netscape mail reader to stick with fixed pitch font? As they said in the movie Dune, "They tried and failed" "They tried and died") FCUSTKEY IP AF K DISK FNOTEKEY IS AF K DISK FNOTEDUP UF F K DISK F NOTEREC KRENAME ORPHAN ICUSTREC 01 I MCUST M1 INOTEREC 02 I NCUST M1 C KEYLST KLIST C KFLD NCUST C KFLD NDATE C KFLD NENTRY C 02NMR EXSR DELETE Orphans C*------------------------------------- C DELETE BEGSR C KEYLST CHAINORPHAN 90 C DELETORPHAN C ENDSR C* ------------------------------------- I'm sure that this type of thing is restricted for the Q&D (quick and dirty) programs that are NEVER put into production :) On a slitely more serious note, I don't mind answering questions. It educates. That's what we are doing on this list. We really didn't need to do all of this, we could just perform a DELET function in the customer edit program then do a READ loop and delete all dependants. But we wanted an undelete option. Which left us with a need to remove orphans. After all (tounge back in cheek) ladies and gentlemen, this IS RPG. Know it's strengths or we might as well be writing COBOL. Now THAT almost gave me the willies! -- =================================================== James W. Kilgore | Progressive Data Systems, Inc. President | 311 31st Ave SE (206) 848-2567 | Puyallup, Washington 98374 USA qappdsn@ibm.net | http://www.ultimate.org/PDS =================================================== * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the Midrange System Mailing List! To submit a new message, * * send your mail to "MIDRANGE-L@midrange.com". To unsubscribe from * * this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe MIDRANGE-L' in the body of your message. Questions * * should be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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.