|
Scott wrote: > I could knock off an e-mail sending routine in 10-12 hours. > Excel writing would take hundreds of hours for me to write. *You* could do it. But could any of us (who don't possess your thorough knowledge of socket programming) do it in 10-12 hours? Not hardly. But there are a million documented examples of people using the JavaMail API, and a nice redbook that deals with calling Java methods from RPG. Elegant? Maybe, maybe not. Depends upon your point of view. Sure, I'd much rather have an all RPG method of sending mail that does *not* rely upon MSF or the AS/400 native SMTP server. But until someone gives it to me, I'm sticking with RPG calling Java. And that's not the only place we're using it. I need to convert image file formats on our iSeries. What we're using now can only convert from MO:DCA to GIF, and the company that wrote it went out of business. But I can find plenty of Java solutions for this, and have bought one and wrapped it with RPG. We have a need to read barcodes in image files (TIFF's, GIF's, etc.), and I can't find a single iSeries solution that will do this. Again, we're going with Java, wrapped with RPG. Would I rather have pure iSeries code? Absolutely. But in the meantime, I've got to get my projects done. Mike E. Scott Klement <klemscot@xxxxxxxxx To: RPG programming on the AS400 / iSeries com> <rpg400-l@xxxxxxxxxxxx> Sent by: cc: rpg400-l-bounces@xx Subject: RE: Catch 'n release MONITOR'd message drange.com 07/19/2003 02:12 AM Please respond to RPG programming on the AS400 / iSeries On Fri, 18 Jul 2003, Bartell, Aaron L. (TC) wrote: > > >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. No, I e-mailed you saying that I couldn't get the IBM porttion of the XML parser. You told me you were trying to get IBM to let you keep in on your site since they removed it from theirs... never heard anything else. > 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? Absolutely. If they agree to implement these, are you going to wait for them, or just implement it with whats available today? I had the impression that you were going to do the latter. > 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. I agree completely. > 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. Yeah, I see what you're saying. But, try doing XML in RPG III once... You'll quickly see that RPG IV is vastly superior for those sorts of things... no comparison at all. Yet, IBM is having a really hard time -- even so many years later -- of getting people to migrate. The average iSeries shop doesn't think that RPG III limits them! I find that nearly impossible to grasp. By contrast, C (which is what Java's syntax is based upon) was doing decent string handling long before RPG IV existed. The people using that were crying out for even more advanced methods, and that's where languages like sed, awk, perl and Java came from. In fact, I've always thought perl would be a great language for XML... > 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? There's a HUGE difference between writing e-mails and excel documents though. I could knock off an e-mail sending routine in 10-12 hours. Excel writing would take hundreds of hours for me to write. In fact, this is a good example, because I recently started writing RPG routines to make excel documents. I worked on it for a significant amount of time before finally deciding it wasn't worth it, and using HSSF from the POI project. So, I have first hand knowledge of how the internals of excel documents work, and how difficult they are to implement... believe me, there's no comparison between that and e-mail :) E-mail would be more similar to my FTPAPI project in scope. Actually, it'd be somewhat smaller in scope than even FTPAPI... > 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. I think the main reason for this isn't that Java is a better language to write e-mail applications, but rather that the programmer who wrote the java mail interface did a better job than the ones who have written the RPG interfaces you've looked at. I wrote an RPG interface for sending e-mail at my company, and I find it quite easy and flexible... but of course, since I wrote it it's designed my way. I've been tempted to write an open-source version (since my original one belongs to the company, and I can't distribute it) but I just don't seem to have any time. Between my tutorials, answering peoples questions, and my existing open source projects I just don't have time for anything else. (right now FTPAPI and TN5250 are both consuming tons of time) Sigh... I really need to win the lottery so that I can quit my job. Then I'd have a lot more time for these things!! _______________________________________________ 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.