|
I strongly agree with David's comments on direct modification to MAPICS code; I will go one step further to apply the same standard to ANY third-party/purchsed code. One of the first issues with our involvement with MAPICS was to set a policy that no source code was to be brought in-house (Note: with the introduction of source code access via the Internet, this could present more of a security issue for some shops). The intent of this policy was to 1) contain the responsibility of code-content and program-fixes/PTFs to MAPICS Support, 2) maintain auditory control and 3) reduce the required overhead during Cumulative PTF application and Version/Release upgrades. I find the task of integrating MAPICS Applications to our Legacy Applications enough of an effort without adding the burden of re-applying completed changes in the event of an applied PTF. As David had mentioned, any non-MAPICS procedures or programs dependant on MAPICS data should be isolated in it's own library (which can be added to the MAPICS default library list via CAS) and trigger programs used to capture 'transient' data in the many transaction workfiles. Even though the 'vanilla' applications can often be viewed as falling short of providing the tailored functionality of customized code, I find that (in many cases) the flexibility to change internal processes can come a long way in meeting the needs of the end-users as well as management. Not to say that these changes come easy, but they must be weighed against the IS maintenance issues that arise if they are not pursued. regards, Tom Ashworth MIS Manager, Altec Lansing Technologies Inc. Routes 6 & 209 Milford, PA 18337 tashwort@altecmm.com 570-296-1276 > -----Original Message----- > From: David Leland [SMTP:dleland@net-link.net] > Sent: Monday, July 19, 1999 6:41 PM > To: MAPICS-L@midrange.com > Subject: RE: Modifications & Maintenance > > In case you haven't yet discovered it, modifications are a real catch-22. > They seem to be so innocent and painless when you make them, but at that > point you've crossed over the line and have now made the upgrade process a > lot more work. My real advice would be to take out all the mods you've > made > and go vanilla code. If you absolutely can't do that, then make your mods > as invisible to MAPICS as possible. By that I mean, try not to make > direct > modifications to program code - instead use other techniques like database > triggers. > > I fight all proposed modifications tooth and nail and make 'em show me a > real business benefit for it and then I try to make them in a way that > will > disturb the least amount of MAPICS code. Lastly, I document all mods with > the thought in mind of future upgrades. > > I've been down the mods route and it is not pretty. > > Dave > > > -----Original Message----- > > From: owner-mapics-l@midrange.com [mailto:owner-mapics-l@midrange.com]On > > Behalf Of Bob Randall > > Sent: Monday, July 19, 1999 9:43 AM > > To: MAPICS-L@midrange.com > > Subject: Modifications & Maintenance > > > > > > What a topic. Does anyone have any advice on how to stay up with > > maintenance > > and continue with modifications? I have several mods to MRP, but > > now need to > > update maintenance on COM. Of course I can't do COM without CAS, and > can't > > do CAS without MRP, gotcha. > > > > I am considering applying maintenance to a separate environment and > > comparing programs afterwards. Cumbersome, but maybe my only option. > Other > > directions or thoughts are welcome. > > > > Bob Randall > > Airxcel, Inc. > > > > > > +--- > > | This is the MAPICS Mailing List! > > | To submit a new message, send your mail to MAPICS-L@midrange.com. > > | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > MAPICS-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > > dshaw1@infoave.com > > +--- > > > > +--- > | This is the MAPICS Mailing List! > | To submit a new message, send your mail to MAPICS-L@midrange.com. > | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. > | To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > dshaw1@infoave.com > +--- +--- | This is the MAPICS Mailing List! | To submit a new message, send your mail to MAPICS-L@midrange.com. | To subscribe to this list send email to MAPICS-L-SUB@midrange.com. | To unsubscribe from this list send email to MAPICS-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dshaw1@infoave.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.