|
<snip> I'm not familiar with MSF. I was suggesting that it write the mail via the SMTP protocol to a SMTP server. If you need to do mail using other protocols, then my ideas probably won't work. I guess I just assume everyone is using internet standard mail. </snip> You don't want to be familiar with MSF :-) I guess I would view that as a fairly hardy project to build an RPG utility that adhered to the W3 SMTP standard; hey, let's use JavaMail. >I also don't use the AS/400 as my SMTP server. It's just not what the AS/400 is good at :) I agree :-) Although there may be a good Java SMTP server you could install on your 400 under Tomcat <VBG> >Huh? Why would you write software that has restrictions that you don't want? I'm suggesting writing it yourself, not using an existing package! I am talking about other email software that I have used that finally drove me to write my own email tools so I didn't have limitations. >But, that parser isn't available. :) I've tried to install it! Hmmm. . . that's funny. I don't recall any of your installation problems being posted to the Installation forum on sourceforge (http://sourceforge.net/forum/forum.php?forum_id=286508). Just kidding :-) Seriously, if you are having trouble installing it, I am just an email away (aaronbartell@xxxxxxxxx). Also, the latest version, with a full install program, can be downloaded from my site http://mowyourlawn.com/files/rpg-xml-parser%20(full).zip. <snip> But, as far as writing statements like: Email_MsgFrom('klemscot@xxxxxxxxxxxxxxxxx'); Email_AddRecipient('aaron@xxxxxxxxxx'); Email_AddRecipient('rpg400-l@xxxxxxxxxxxx'); Email_Subject('Fun with salt shakers'); Email_BodyFile('/tmp/bigbody.txt'); Email_Attach('/tmp/happyboy.gif': 'IMAGE/GIF'); Email_Attach('/tmp/sillyreport.xls': 'APPLICATION/VND.MS-EXCEL'); if (Email_Send('smtp.klements.com') < 0); SndEscape(Email_Error); endif; I don't see why there'd be scalability issues there. </snip> For one, I want RPG to advance faster as a language. Shouldn't I be able to easily throw an error and have the MONITOR statement catch it? Shouldn't I be able to use ALIAS'd file field names in my RPG? Shouldn't I have dynamic arrays? The list goes on and on of things that make the language hard to use, and even harder when you try to get into anything that has to do with XML. I am sure Hans and Barbara (those are the only two I know) do quite well with what IBM gives them for resources, I just wish IBM would take RPG more seriously. My comment about scalability leans more towards my first effort of making an RPG interface to a Java Servlet running on Tomcat with XML as the transport. I'll be darned if it is easy to make an application that can handle all loads of different repeatable data segments in RPG. It just doesn't fare to well. First you hit the roof if you try to store large amounts of data in a variable (32K or 65K). Once you realize those are too small for a "robust" app you go looking for other things like User Spaces and temp files in the IFS. If you store info in the IFS (which can be huge amounts and you are not really limited), you eventually need to bring that back into an RPG program which has strapped variables like I previously mentioned. This isn't a problem if you can stream (in large chunks) your IFS file to the service of choice, but if you have 3rd party code that didn't think a data stream should ever be over 32K/65K then you have to deal with those limitations. You can definitely make it work, but the motions you go through to make it work take way too much time, and your failure points multiply. I am not a top notch RPG programmer, so maybe that is where some of my comments come from. <snip> If you're so keen to do your e-mail in Java, then why are you writing an RPG interface for it? It seems to me that your major problems is that you're mixing both RPG and Java. Do it purely in Java if you want Java. </snip> So I can send emails from RPG programs. RPG is still the main stay in our shop, and I don't see it leaving anytime soon. Programmers can pound out business code like crazy with RPG (which is where RPG serves its master well). Case in point, you could build your own RPG routines to compose Excel documents, but why would you when you could interface with solid Java code like POI(http://jakarta.apache.org/poi/). Lane McBride (on this list) took the Java POI classes and put an RPG interface on it, and now we have RPG-only programmers dynamically creating Excel spread sheets, and doing it with relative ease. Now how long do you think it would have taken to build that with RPG? 3 months, 6 months, 1 year? and would it be sufficient even then? My opinion is that too many times we use RPG as the wrong tool for the job, or we try to re-create the wheel. RPGMail is my 4th iteration of trying to get emails to work on the iSeries, and I think I finally have something that will work good. And that is because I finally released RPG from having to do it from the ground up. Those are just my opinions on the matter. Aaron Bartell -----Original Message----- From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx] Sent: Friday, July 18, 2003 6:25 PM To: RPG programming on the AS400 / iSeries Subject: RE: Catch 'n release MONITOR'd message On Fri, 18 Jul 2003, Bartell, Aaron L. (TC) wrote: > > 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. I'm not familiar with MSF. I was suggesting that it write the mail via the SMTP protocol to a SMTP server. If you need to do mail using other protocols, then my ideas probably won't work. I guess I just assume everyone is using internet standard mail. I also don't use the AS/400 as my SMTP server. It's just not what the AS/400 is good at :) But that's not really relevant, a program can be made configurable so that it talks to any SMTP server, whether it's on the LAN or Internet or local machine is just a matter of specifying a different address. > 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. Huh? Why would you write software that has restrictions that you don't want? I'm suggesting writing it yourself, not using an existing package! > 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. But, that parser isn't available. :) I've tried to install it! But, as far as writing statements like: Email_MsgFrom('klemscot@xxxxxxxxxxxxxxxxx'); Email_AddRecipient('aaron@xxxxxxxxxx'); Email_AddRecipient('rpg400-l@xxxxxxxxxxxx'); Email_Subject('Fun with salt shakers'); Email_BodyFile('/tmp/bigbody.txt'); Email_Attach('/tmp/happyboy.gif': 'IMAGE/GIF'); Email_Attach('/tmp/sillyreport.xls': 'APPLICATION/VND.MS-EXCEL'); if (Email_Send('smtp.klements.com') < 0); SndEscape(Email_Error); endif; I don't see why there'd be scalability issues there. If you're so keen to do your e-mail in Java, then why are you writing an RPG interface for it? It seems to me that your major problems is that you're mixing both RPG and Java. Do it purely in Java if you want Java. _______________________________________________ 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.