RE: Supressing all screen/print output

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