Why Java on the AS/400

[Guest.Visitor]

I have heard many reason why Java was chosen for the AS/400. I remember that one reason was that Java was the answer to have a native GUI interface on the AS/400. Can anyone let me know if this is correct. I know that there are many reasons, and would appreciate any info that is shared with me. I am gathering info to defend RPG and the AS/400. Thanks

[J.Pluta]

<font color=red>On Monday, March 15, 1999, 05:35 AM, Larry Emery wrote: I have heard many reason why Java was chosen for the AS/400. I remember that one reason was that Java was the answer to have a native GUI interface on the AS/400. Can anyone let me know if this is correct. I know that there are many reasons, and would appreciate any info that is shared with me. I am gathering info to defend RPG and the AS/400. </font><hr> What's to defend, Larry? I'm probably the second-biggest Java advocate on this site (Don is our absentee guru... you there, Don?), and I'm a big fan of RPG and the AS/400. In fact, my architecture of choice is a Java GUI on the PC talking via data queues to RPG servers on the AS/400. I've just gotten done taking a "monolithic" file maintenance program written in RPG (by monolithic, I mean a single program that does screen and database I/O) and splitting it into two RPG programs: a client that only talks to the screen and a server that only accesses the database. The two communicate with one another via messages. Then, I rewrote the client in Java on the PC, but left the server in RPG up on the AS/400. The Java client calls the same message interface to talk to the server that the RPG client does. What did I get? A file server that could support both green screens AND Java GUIs simultaneously. I could make a change on the PC and see it reflected in the green screen. It was VERY impressive. The AS/400 is by far the best business application data server on the market today. Given its speed, scalability and above all, it's incredible reliability and low cost of ongoing ownership, it simply cannot be beaten. RPG is currently the language of choice for server-side development (IMNSHO) because server-side Java is not yet fully integrated into the operating system (Java programs must run in a separate "shell"; they cannot be executed directly from OS/400). Anybody who says different should write a simple item master maintenance program like the one I wrote in whatever architecture they think is superior. My two cents. Hope it helps. <a > href="//www.zappie.net/java"><img > src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle"></a>

[J.Pluta]

<font color=purple>On Monday, March 15, 1999, 05:35 AM, Larry Emery wrote: I have heard many reason why Java was chosen for the AS/400. I remember that one reason was that Java was the answer to have a native GUI interface on the AS/400. Can anyone let me know if this is correct. </font><hr> One additional point, Larry. There still is no native GUI for the AS/400. When writing in Java, there is a "workaround" called remote AWT, in which you write as if you were on a PC. Then, when you run the program on the AS/400, all the data is sent down to an attached PC to be displayed. From what I understand, it works, but it's very slow. On the other hand, Java on the AS/400 will not talk to display files, so in effect, there is NO native user interface of any kind for server-side Java. <a > href="//www.zappie.net/java"><img > src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle"></a>

[Guest.Visitor]

On Monday, March 15, 1999, 07:11 AM, Joe Pluta wrote: <font color=purple> There still is no native GUI for the AS/400. </font><hr>This is not exactly true. Several years ago IBM produced a 5292-2 terminal which displayed GDDM graphics along with the regular 5250 data stream. The 5292-2 Terminal may still be emulated with CA/400 for DOS! <tt>I hope I have the correct terminal number</tt> The <u>easy</u> method of producing GDDM graphics was through BGU. This could have been developed over the years, to produce real easy to use 5250 data stream graphics, but it never was! Along with V2R3 came the ability to use pull downs, buttons, menu bars, etc. This could also have been developed fuller, but hasn't. Along with CA/400 comes a subset of GUI/400 called GA/400. This shows that the 5250 data stream has the capabilities of being as graphical as anything else. The fact that IBM has chosen to include about 10% of this package with CA/400 has led to a lack of enthusiasm among CA/400 installers. IMHO If IBM updates their 5250 data stream, there will be less user resistance to native 5250 apps. It can be done, It has been done, and it is being kept a secret very well. David Abramowitz

[J.Pluta]

<font color=blue>On Monday, March 15, 1999, 10:40 AM, David Abramowitz wrote: Several years ago IBM produced a 5292-2 terminal which displayed GDDM graphics along with the regular 5250 data stream. The 5292-2 Terminal may still be emulated with CA/400 for DOS! Along with CA/400 comes a subset of GUI/400 called GA/400. This shows that the 5250 data stream has the capabilities of being as graphical as anything else. The fact that IBM has chosen to include about 10% of this package with CA/400 has led to a lack of enthusiasm among CA/400 installers. IMHO If IBM updates their 5250 data stream, there will be less user resistance to native 5250 apps. It can be done, It has been done, and it is being kept a secret very well. <hr></font> If the IBM JVM directly translates the Java primitives to write to the 5250 data stream, it begins to sound interesting. The next trick would be to somehow turn on "5250 graphical mode" on your workstation, allowing you to develop Java programs that wrote to this 5250 standard, and then emulate the results using CA/400. It's an interesting thought exercise, that's for sure. <a href="//www.zappie.net/java?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJvkG9"><img > src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Zappie's Java Home" align="middle"></a>

[Guest.Visitor]

<font color blue>On Monday, March 15, 1999, 05:35 AM, Larry Emery wrote: I have heard many reason why Java was chosen for the AS/400. I remember that one reason was that Java was the answer to have a native GUI interface on the AS/400. Can anyone let me know if this is correct. I know that there are many reasons, and would appreciate any info that is shared with me. I am gathering info to defend RPG and the AS/400. </font> I'd be suprised if IBM hoped that Remote AWT would be a driver for people to use Java on the AS/400. Especially since in Java2 everyone is using SWING (so IBM would need to create/sell RSwing ??) It would probably help us help you if you could be more specific about what are you trying to defend. (i.e <ul> need to integrate with new applications/channels/components that are java based ? need a way to modernise your existing application functions ? The business wants to start using Java as a language ? [/list] E.G. I see on V4R4 IBM will deliver on upgrading the VisualAge RPG tool that to produce JavaByte Code. Joe has shown one technique to leverage your existing RPG investment into a Java based environment. You could also look at how Intentia mirgated their Movex ERP application which was RPG code to Java. (With some IBM help) David

[Guest.Visitor]

David Bye is right, we need more explanation about the potential use for Java at your shop. Like many of the respondants to your query, I have coded on the AS/400 in C, C++, MI, RPG, Cobol, and Java. Each of these languages has their strengths. But, in general: Why Java on the AS/400? First, for Internet applications. Java works well (OK, maybe it works but not perhaps not well for bandwidth reasons) for thin clients. Java for server-side applications works well because the product is then cross-platform. Every week, it seems, a new product is made available for the AS/400 that was initially developed for Unix or whatever. It is available for the AS/400 because it was developed in Java. Bluestone's Application Web server and BEA's Weblogic are two example of pure-java applications that work well. Why Java on the AS/400? because many shops can't get RPG programmers. Check out the median age of programmers at Common. Most of the men attendee's, like me, now shave their ears as well as their face. Why the lack of young talent? Because the college graduates don't know RPG or Cobol and, anyway, they prefer to work with OO languages like C++ and Java. Or they want to work with "modern" (hey, not my words) (Joe, get a paper bag handy) like powerbuilder or peoplesoft. Why Java on the AS/400? Because object-oriented design and programming has proven to be a superior strategy to structured programming. Sure, you can develop ILE RPG applications that are close to OO but they still won't quite have the full advantage. Why Java on the AS/400? Because CASE has largely failed. The latest solution to RAD is to use JavaBeans in a component oriented fashion to snap software from various third-parties together. Plus everyone modified the code generated from CASE thus breaking its strength. With OO and Java you NEVER modify code rather you extend it in the design of a new class. Why Java on the AS/400? Because in the very near future the best application software will be available as Java classes. Most of the biggest and greatest software vendors have already moved to Java. When CIOs see these tools and discover the benefits of extending packaged software versus modifying packaged software, many AS/400 shops will be working with Java. Why are these companies moving to Java, after all, many of them are or were pure RPG development shops? Because what software vendors know more about business software than the same vendors that creates accounting, manufacturing, and sales software for the System/3, System/36, System/38, and the AS/400. These companies no longer want to limit their software to RPG platforms. They know they have the best knowledge about business software and they want to market their product to companies whose platforms are Solaris, Intel, RS/6000, S/390, as well as the AS/400. These vendors also have seen the benefits of code reuse in OO, many have dabbled with C++ and now Java is the answer. They are hitting Java big time and how many of us AS/400 programmers have never worked with a package from a major vendor before. I'd say 80 percent of us live with packages on a daily basis. Why Java on the AS/400? Because it's very productive and so so much fun to code with.