|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.