|
>if you can program an OO MRP generation, including >coproducts and byproducts, dependent and >independent demand, batch balancing, and all the >other features we require in ERP systems, amd it >runs as fast as it does in RPG, then you've reached a >point where perhaps OO can be used for business >programming (BTW, SQL still fails this particular >benchmark). Hi Joe! I can only comment on two parts of your post, being of limited OO experience. Performance. It is not farfetched to envision a hardware JVM that is VERY efficient for Java and much less so for RPG. It's not here today, but the probability of better performance means that I feel somewhat at ease disregarding the performance aspect of your challenge for the moment. MRP generation. Java may indeed pee a very poor fit for MRP generation, but I don't think that because Java is poor at one sort of business application, it's poor at all sorts of business applications. I wouldn't use RPG for geographic based systems (say least cost truck routing.) I could, especially now that I don't have to write the higher match functions myself, but it wouldn't be pretty, nor would it be a screaming performer. Just because RPG can't do THAT sort of business programming doesn't mean it's bad at all sorts of business programming. Far more typical than either of these extremes are customer care, order entry, shipping, blah blah blah. (And you can quote me on that.) Let me set up an example from my current industry - telecommunications. We'd like to extend our customer care application to the web (look Ma, I'm on topic!) so that say, students can set up their phone service when the move into a dormitory, change their service plans at a whim and check out/close the account at the end of the school year. Extending to the web is somewhat of a misnomer, because self-service is quite beyond our existing green screen capabilities. There are in fact, very few existing functions that would support self-service. So, there is going to be some application development. We have Delphi programmers who can build a thick client (which actually looks and works great), we have Java folks who can write applications, applets or servlets, we have RPG folks who can write server-side programs. We may end up with a mix of languages on the iSeries, or nothing at all but a JDBC server there. The technical decision will ride on the business requirements. There's no single answer that's 'right' of course, which is why I think the blanket "Java isn't that good for business programming" needs some fine tuning. Best regards! --buck (cheerily using MHLZO since July 1978 and defending Java anyway...)
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.