|
What are you talking about? The Java portion? I wrote it in Java because whenever we rely on MSF (Mail Server Framework) it blows up and we end up restarting it without retaining the existing queue entries (or whatever they are called), which means we lose all of the emails that are waiting to be sent out. We have 25+ iSeries machines that we support and MSF became such a problem that we had to find a different way to send out email. Also, I don't have to deal with all of the restrictions that other software out there has (limited attachments, limited recipients, etc). I already knew Java, and the JavaMail API's do all the hard work for you. If somebody has an RPG email product out there that doesn't have limitations and doesn't use MSF and is really fast and doesn't cost an arm and a leg - shoot me an email. But as of right now, this is the most reliable, and feature rich (and it isn't even that rich) email utility we have. (Notice I didn't say fast, it is Java after all :-) Besides, RPG doesn't scale well for these types of things, IMO. Like the RPG XML parser I just got done writing; I wouldn't recommend parsing XML in RPG, but if you don't have any other options, that parser is available and works good. Aaron Bartell -----Original Message----- From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx] Sent: Friday, July 18, 2003 5:08 PM To: RPG programming on the AS400 / iSeries Subject: Re: Catch 'n release MONITOR'd message Why not just write the software in RPG in the first place? Then you can handle the errors without all this additional complexity. On Fri, 18 Jul 2003, Bartell, Aaron L. (TC) wrote: > Here's my deal. I have the following sub procs which interface with java > methods, and if a java exception is thrown I want to catch it in my > RPGMail_xxxx sub procs, parse it, and relay a more friendly error back to > the calling program. Once I have "caught" the "percolated" error is there a > way to 'un-catch' it so the error continues to percolate up to the next > calling program so it errors out with its MONITOR, and once errored out goes > to look in some additional error sub procs I have setup? > > > Monitor; > email = RPGMail_new(); > RPGMail_addAddress(email: 'FROM': from: 'Aaron Bartell'); > RPGMail_addAddress(email: 'TO': to: 'Larry Boy'); > > RPGMail_setSubject(email: 'This is the subject line'); > > RPGMail_setBodyFile(email: '/tmp/news.html': 'text/html'); > > RPGMail_addFileAttachment(email: '/tmp/Example3.xml': ' ': ' '); > > RPGMail_setSMTPHost(email: 'smtp.mycompany.com'); > RPGMail_setSMTPPort(email: '25'); > > RPGMail_send(email); > On-Error; > errors = RPGMail_getErrors(); > EndMon; > > I have tried producing errors with callbacks, but if an error is encountered > on RPGMail_addFileAttachment, I don't have a way to say don't process the > next three sub proc calls (RPGMail_setSMTPHost, RPGMail_setSMTPPort, > RPGMail_send). I could return a value on each sub proc call to indicate > whether or not it errored out, but that makes the code look really messy > ('If' statements everywhere). > > Thanks for any help you can give, > Aaron Bartell > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
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.