|
With all due respect, it sounds like you have a bigger problem than trapping messages. If you could insure that things are properly tested *before* they hit production, you would have significantly fewer issues to be concerned with. Change management is an important control point for *every shop*; it shifts the burden of discovery to a point *before* the user community is affected. While change control *is not* a panacea, it *does* make management of systems significantly more proactive in nature. The Software Engineering Institute (SEI) at Carnegie-Mellon (http://www.sei.cmu.edu/) has a maturity model to define and help improve a shop's capability; the second level of improvement identifies the need for a change management control process. As developers, we tend to look to technology to solve our problems. We must balance this with the needs of the business, as well as defining and increasing our shop's own capability to provide quality deliverables to our users. Developers (and IT mangement) must be pragmatic enough to realize that sometimes, "good enough is good enough." IMHO, the entire implementation of Java and the IFS as it exists on 4r4 is less than optimum; for now, however, it's the only game in town and I have to use it. We've learned that 90% of our issues are the way we work, not an issue with technology. For our email application, we trap everything we can and println error constants that stand out (i.e. ****ERROR:). Then, we can scan the PF generated by the OVRDBF looking for errors. It is not the most robust solution but it has served us well. In essence, it is quite similar to what many people do with batch FTPs. Sorry for the long post; I've been watching the election returns and after all the speeches, I think something rubbed off. dan -----Original Message----- From: Clapham, Paul [mailto:pclapham@core-mark.com] Sent: Tuesday, November 07, 2000 4:14 PM To: JAVA400-L@midrange.com Subject: RE: Supressing all screen/print output Java programs occasionally fail for no apparent reason on our systems (or because some careless programmer, no names mentioned, changes the class's input parameters but not the CLs that call it), and it's better for us to know that at the time it happens. +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
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.