In defense of the lowly MR -- MIDRANGE-L

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   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *