× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Logical file access paths
  • From: "Shaw, David" <dshaw@xxxxxxxxxxx>
  • Date: Wed, 19 Apr 2000 10:45:41 -0400

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.