|
in essence implemented on a system that is already running a decent
workload, does not have enough memory, is utilizing an older processor, is not written very well, etc. Interestingly enough, these are all things that we "can get away with" when coding RPG. Yes an RPG program can still kill a system, but I think that happens much less often than in the Java environment. I didn't put the word "scholarly" in there simply because I was lacking word choice. You have to know A LOT about the ins and outs of Java components to 'get it right' when creating a large application with the potential for a lot of concurrent users. In RPG you are there much quicker. Good to hear about your other failures to successes with Java. I don't hear much of the successes believe it or not. But like you commented in #1, a lot of these things could/should simply be implemented in RPG as that is the language most shops support. Introducing a new language into the mix in any shop has MANY ripple effects (think QA, Support, Training, Debugging, Split knowledge on multiple platforms, etc) Thanks for your comments Mike, Aaron Bartell -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Crump, Mike Sent: Wednesday, March 28, 2007 8:33 AM To: Midrange Systems Technical Discussion Subject: RE: Platform Independence (was George is Farr from where we want tobe) Platform independence? Not very. We use JAVA more so to allow for using the ubiquitous browser and for independence from MS. Although, I would also have to respectfully disagree with some of Aaron's points. While I would not argue that plenty of people have horror stories regarding native Java performance I think that you will find a lot of them are of there own making - in essence implemented on a system that is already running a decent workload, does not have enough memory, is utilizing an older processor, is not written very well, etc. 1.) We have a native JAVA program that processes our finite scheduling system. This is program that does a lot of IO and I argued up front that it should have never been written in Java because it was a classic fit for RPG. I lost but I will have to say that application runs blazingly fast and processes many functions and millions of records. I doubt that we would see any improvement if it was converted to RPG. In addition, by most testing it is as fast as running it on an independent WINTEL platform. I have compared it run wise on our i5 to an IXS system (to eliminate remote database issues) and there is no comparison. Right now, I am not in the position to test on a faster Bladecenter type of unit but perhaps in the future. The database is remote to the native application as well. 2.) We originally implemented WAS (v3) on a 720 years ago. 80% of the application runs perfectly fine but certain components were a dog. Processor was not being taxed, we were not short of memory, we just did not have the processor crank and L2 cache that the application needed. Shortly thereafter we upgraded to an 825 and 100% of the application ran fine. A classic example of implementing Java in a not so perfect platform. I would argue that as we have climbed the server ladder 7xx, 8xx, 5xx the potential for this problem has decreased. 3.) We run WAS and WPS on our 570's and generally speaking these guys perform very well. Our major complaint on WPS comes from portlets that we rely on our parent company for and their responsiveness is not very good. 4.) The native JVM can be a resource hog. That is why the J9 was invented. Certain machines and customers should not be running the native JVM. They do not have the horse for it. Is it a problem with the native JVM? Perhaps. I would just argue that it is as much environmental as it is platform. I cannot argue with the complexity. However, I think that this is not a JAVA problem only. Every existing 'modern' application is much more complex than the traditional RPG model. Whether it is Java, .NET, Domino, etc. I think that they are much more complicated either in architecture or in resulting code length. Michael Crump Manager, Computing Services Saint-Gobain Containers, Inc. 1509 S. Macedonia Ave. Muncie, IN 47302 765.741.7696 765.741.7012 f Cluelessness There are no stupid questions, but there are a LOT of inquisitive idiots. This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Saint-Gobain. If it did, it would be folded, mutilated, watered down, politically corrected, and would show up a week later if at all. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Ryan Sent: Wednesday, March 28, 2007 8:10 AM To: Midrange Systems Technical Discussion Subject: Platform Independence (was George is Farr from where we want to be) How important is platform independence to the community? It has little importance to me. I believe RPG is the best language on iSeries, and I don't need to write the same code to run on multiple platforms. I *do* write code on multiple platforms (VB and C on Wintel), but I don't expect or want to run the *same* code on other platforms. On 3/28/07, albartell <albartell@xxxxxxxxx> wrote:
While in that session I was very close to asking the group whether
they gave
a rip about platform independence.
-- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-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.