Re: Logical file access paths

Hi David,

Thanks for the info. I have yet to actually work with Mapics, it was just a
rumour - glad to know the facts before I run into them!

Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax

----- Original Message -----
From: Shaw, David <dshaw@spartan.com>
To: <RPG400-L@midrange.com>
Sent: Wednesday, April 19, 2000 7:45 AM
Subject: RE: Logical file access paths


> Peter,
>
> Comments at end regarding your statement about MAPICS:
>
> > -----Original Message-----
> > From: Peter Dow [mailto:pcdow@yahoo.com]
> >
> > Hi Lewis,
> >
> > That method dates back to when a program was not allowed to
> > change a key
> > field. The drawback is you end up with a bunch of deleted
> > records in the
> > file unless they are all set to re-use deleted records (a
> > relatively recent
> > innovation<g>) or do a regular RGZPFM.
> >
> > I hear MAPICS apparently uses a similar technique and has a
> > large ratio of
> > deleted to active records in their files. One of my customers
> > recently had
> > to do some mass updates to large files and during testing
> > discovered that
> > hey! 70% of this 3 million record file is deleted records.
>
> No version of MAPICS for the /38 or /400 that I've ever seen does deletes
> and adds instead of doing key-change updates.  In most forms MAPICS does
> require regular housekeeping for deleted records, but this is because of
the
> normal flow of processing.  For example, when a purchase order is closed
its
> records are deleted from the open purchase order files, and copies are
> written to the purchase order history files.  This does result in large
> numbers of deleted records in the open purchase order files.  From a
> database design standpoint it might make more sense to keep all purchase
> orders on the system in one set of files rather than having two sets, but
> historically MAPICS has always been more concerned about disk space and
> processing efficiency of the "current" files, with the "history" files
being
> a secondary issue.
>
> MAPICS ships many of its files with REUSEDLT(*YES) in current releases -
in
> fact, it could be all of the files by now, I haven't seen what a scratch
> install does in many years.  There's no reason that I'm aware of that
would
> prevent a MAPICS customer from setting them all that way himself, unless
he
> uses something like DataMirror which puts restrictions on that (DataMirror
> Transformation Server, at least at releases through 4.2, can't mirror a
file
> by relative record number if it's set to REUSEDLT(*YES) - and MAPICS has a
> number of files which don't have a unique key access path to use instead,
so
> mirroring by RRN is necessary.)
>
> Dave Shaw
> Spartan International, Inc.
> Spartanburg, SC
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---