× 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: Modifications & Maintenance
  • From: "Ashworth, Thomas R." <TAshwort@xxxxxxxxxxx>
  • Date: Tue, 20 Jul 1999 08:51:52 -0400

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 thread ...


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.