Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

RPG and DB2: The Future Is Now

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #46
    RPG and DB2: The Future Is Now

    ** This thread discusses the article: RPG and DB2: The Future Is Now **
    Darryl said: "Would you spent half a million dollars to upgrade an 820 to an extra processor, and RAM and disk increases, or would you spent a quarter of that cost to buy a handful of x86 machines?" We'll be upgrading our 820 later this year and in the process will have a CPU 4x faster. The cost: Under $100k. Where did the half million number come from? chuck Opinions expressed are not necessarily those of my employer.

    Comment


    • #47
      RPG and DB2: The Future Is Now

      ** This thread discusses the article: RPG and DB2: The Future Is Now **
      Thank you, Thank you, Thank you! I appreciate your article and am looking forward to part two. It is refreshing to see your point of view in that some languages are better at some problems than other languages are. I am getting real tired of hearing that Java is the panacea for the programmer, and we should all drop everything we are doing and jump on the Java bandwagon; and yes, Common Sense does seem to be taking a back seat to all of this! I am also tired of the Java crowd telling us it’s the best because it is platform independent. It is only platform independent for those vendors who develop a JVM for it, as far as I am concerned. If I have a machine that has Java on it, but no JVM, I cannot run Java. The same goes for BASIC, FORTRAN, COBOL, RPG, and others. The difference is that they require a compiler, not a “Virtual Machine”. Taken that way, RPG and COBOL can also be platform independent, as long as you get something to interpret or compile it. Both RPG and COBOL can run in the iSeries, IBM Mainframe, PCs and HP machines. I can order a COBOL compiler for the mainframe, a PC based COBOL or RPG product (Microfocus COBOL or Baby/400), and RPG and COBOL both run on an HP product, I am not sure of the model, but I believe it is the HP3000. Given this, both RPG and COBOL would have to be coded in a vanilla mode for this to happen, but the same also goes for Java, I bet. Given all of the players involved, I find it very hard to imagine that a JVM from Sun does not have nuances in it that are not supported by a JVM from IBM and vice versa. So, until someone tells me that ALL Java code, regardless of the hardware it runs on, is cross platform capable, I don’t buy it. I am also glad to read Joe’s assessment of SQL versus native data access. It is very interesting to note that both methods have their strong points in terms of where to use them in developing or maintaining an application. It is interesting to note that native I/O is better at handling single record access that SQL. Not only that, but, in that example, I’d rather code a one line CHAIN command, rather than code a multiple line SELECT xx FROM xxx WHERE statement to get the same result. Again, it just makes common sense. I’d be interested in seeing the performance comparisons, in terms of batch processing, when assembling data from multiple files using one big SQL select statement, or one OPNQRYF file command, coupled with record blocking reads from the sequential result. I did some tests awhile ago with reading sequential data with blocking. I compared using the cycle, versus not using the cycle. The cycle actually ran slightly faster than a non-cycle program, where the data was read inside of a DO loop. Another example of losing common sense, is the use of level breaks. I do not understand why programmers do not use the cycle for level breaks. It saves tons of coding time, and since you are making the machine do more of the work, you are reducing coding errors. Why programmers manually code level break logic, and multiple breaks at that, is beyond me, especially when something like level breaks are an integral part of the language. I agree with Joe in regards to the performance issue too. I did not compare RPG runtime versus Java/SQL access as he did, but I still do not see batch processing as a Java advantage. I can only imagine what a Java sales analysis program would look like, and cringe to see how easily it can be modified when requirements change. I can look at someone else’s RPG code, and while it may not be great, I can very quickly narrow down the point in the program where the logic needs to be changed to meet a new requirement, as compared to doing the same change in a Java program. Has anyone looked at a Java program to try to find out how it does something? I agree with Joe that database accessibility and arithmetic are not Java’s strong points, and I’d add readability to that also. But realize this: Processors will keep getting faster and faster, and the differences “should” become less and less. However, as Java / SQL get faster and faster because of the processors, remember that (as Joe points out) RPG has already had it’s runtime optimized over decades of time. So as the processors get faster, so does the RPG runtime module. It is interesting to note that the iSeries is known as being the best performing Java server available. If you think Java is slow on the iSeries, how much more so is it when performing on a non-iSeries box? Finally, another thing I’d like to see addressed is the perception of Java forcing programmers to have to code to certain standards. As I recall, there was a way for a Java shop to set up routines so that programmers would use those routines to perform common tasks. The programmers could not write those routines, only certain kinds of programmers (senior level?) could write them and place them in production. If this is the case, then the “problem” being “solved” is a management problem, not a programming one. I can have that same set up in RPG, COBOL, etc. It just has to be managed, it is not enforced. Besides, if my senior Java programmer begins to make all kinds of exceptions to the standards, then I do not have standards anymore, and spaghetti is not far away. If a programming shop is not managed correctly, then a Java shop will evolve to what it is not supposed to be: spaghetti. Again, thank you Joe for the great article; I am looking forward to the second part. If I have any of this wrong, or have misunderstood something, please let me know. Doug.

      Comment


      • #48
        RPG and DB2: The Future Is Now

        ** This thread discusses the article: RPG and DB2: The Future Is Now **
        CD, it's just a business decision. In this case, it's the classic make vs. buy decision that any software manager has had to make multiple times in his career. In this case, you're heavily weighting all the factors towards a buy. Of course, you haven't addressed things like user-based pricing, maintenance, company stability, bugs reported, service levels or anything else. If all of those still weigh in favor of the package, then BUY THE PACKAGE. This is common sense. It also in no way supports your position that RPG is dead, and that the best solution for programming is to put tactical nuclear programming applications into the hands of "occasional developers". For example, if I've already got in-house staff, and what is needed is a different presentation because Bob in sales has a nifty new graphics package, then it may make more sense to encapsulate the business logic and provide an XML interface so that Bob can simply download the data he needs as an XML file and feed it into his presentation program. Don't get me wrong, I'm not saying that there's no need for end user tools, or that they can't be smart and sophisticated. I'm just saying there's a lot more to development than inquiries and a whole lot of that development is best done in RPG. Joe

        Comment


        • #49
          RPG and DB2: The Future Is Now

          ** This thread discusses the article: RPG and DB2: The Future Is Now **
          cdr500 said" What if I had a development environment in place that would allow selected end users with special training to provide highly usable output and some usable input?" "What if": is right. First of all I have never seen such an environment. I could be wrong, maybe there is something out there that actually works. Second of all, where I have seen that attempted (JDEdwards OneWorld), it has some advantages, but still requires programmers. We have two on staff. And some 10 people that are non-IT that develop reports. But it takes the programmers to do the work that affects business logic (just as Joe was aluding to). And a steep learning curve for those no-IT people. The deal is that the situation you are talking about sounds nice, but it's not going to happen soon, if at all. Actually, it probably WILL happen, but in MANY more years than people predict. They were predicting computers that would figure out things like that automatically back in the 70's. Saying it would happen in a decade. When code generators came out they predicted that programmers would be obsolete by the mid 80s. Predictions sound good, but the actualy reality is usually very different. Every generation predicts that the newest thing will totally revolutionize the industry, but it NEVER happens. It EVOLUTIONIZES the industry. My point to you is that much of what you say has merit. Some of it is now, but people are ignorant of it. Some of it will happen in the future, and some of it is just wishfull thinking. But NONE of it is likely to doom the large computer platform in the near future, even in the next few decades. And, IMO, that includes IBM, iSeries and RPG. -dan

          Comment


          • #50
            RPG and DB2: The Future Is Now

            ** This thread discusses the article: RPG and DB2: The Future Is Now **
            I find it very hard to imagine that a JVM from Sun does not have nuances in it that are not supported by a JVM from IBM and vice versa. The current reallity is you are more locked into a Application Server, such as WAS or Weblogic. Each app server has some slight nuance. But apart from that we do deploy business components and/or applictions onto different Operating Systems. Although in this case the iSeries is not a target platform. I agree with Joe in regards to the performance issue too. I dont dispute the performance of a SQL and/or JDBC call would be slower. Although To Date performance of a call has not been an issue. I did see the benchmark results of Joe's site and the 5.84 seconds for a single fetch does not reconcile with what I have seen in production environments. All I can think is the benchmark ran the program once as previously running a program once to get a record would have been slow, but leaving that program active subsequent calls were subsecond. I can look at someone else’s RPG code, and while it may not be great, I can very quickly narrow down the point in the program where the logic needs to be changed to meet a new requirement, as compared to doing the same change in a Java program. Yes, but the reverse is a close description for a java developer. How long were you involved in a java based development ? Has anyone looked at a Java program to try to find out how it does something? No we dont do maintenance or bug fixes in java We only do refactoring I agree with Joe that database accessibility and arithmetic are not Java’s strong points, and I’d add readability to that also. AFAIK the issue with java is around Decimal Numbers. IBM has drafted a spec that has been implemented that helps a lot. But the 'telco' Benchmark shows about a 4:1 performance issue between a COBOL environment and java....so I would expect similar ratios for RPG. I dont your assessment the comment on readability, would you care to expand ? I have a slight grin remembering back to when I first saw RPG with its limited length varibales, fixed position etc... It is interesting to note that the iSeries is known as being the best performing Java server available. If you think Java is slow on the iSeries, how much more so is it when performing on a non-iSeries box? This is what sparked my posting.... I didnt know this ! Are you sure this correct. If so than IBM is keeping it a closely guarded secret. The SPEC java server benchmarks are quite dated. But here is a snapshot that doesnt reconcile with the claim. After the model is the number of CPUs in the server and then the perfomance number:
              [*]IBM RS/6000 Model M80 4 37,074[*]IBM eServer iSeries 830-2402 4 17,864[*][*]IBM eServer iSeries 830-2403 8 34,274[*]IBM RS/6000 Model M80 8 72,437[/list]T

            Comment


            • #51
              RPG and DB2: The Future Is Now

              ** This thread discusses the article: RPG and DB2: The Future Is Now **
              Or, you can actually use a modern tiered architecture where the business logic is written in RPG and communicates with whatever application and UI layers you want via messaging. Joe, I agree the tiered architecture with interconnects via messaging is where significnt new designs and development should be targetted. This would be irrespective of the platform providing the data and business layers. I often will use the term "heritage" systems when they are being referred to as legacy. That is the systems we put in years ago are of business value. Where possible we try to expose the proven business rules as business services that can be exploited by new user interfaces, or improved business processes. I think CD's vision is somewhat clouded in a belief that a java environment is a pure environment. I wish this were true, but you can very quickly end up with a myriad of 3rd party or open source packages. Also The messageing architecture also address the inter company transactions or dependencies on other companies to provide informational services. Web Services is the current set of opemn standards that will hopefully simplify this envioronment. These days I spend very little time working in an iSeries environment. I think the iSeries could become a stronger server if it strengthened itself both as a consumer and supplier of webservices.

              Comment


              • #52
                RPG and DB2: The Future Is Now

                ** This thread discusses the article: RPG and DB2: The Future Is Now **
                So does this mean you support a complicated mixtured of technology to override the use of the green screen? The IT department has ALWAYS been a mix of technologies. Whether it was S/3 and 5250 workstations, or S/38 and the Series/1, or iSeries and PC workstations, it has always required mutiple technologies to do the job. Green-screen itself started out as a complicated mixture of technology for its time. It was actually the first client/server application, since the 5250 terminal itself was a powerful computer in its own right. Add to that the 5250 data stream and the communications protocol (SNA on token ring back in the day) and you had a powerful mix of technologies. The fact that you can house most of them on a single box like the iSeries is the evolutionary concept that you seem to be missing. Within one box, we've got everything from RPG to C to Java, OS/400 to Linux to AIX, DB2 to SQL to JDBC, multiple HTTP servers and web application servers and communications protocols, with powerful built in security, scalable processing power and integrated backup. As a developer, I'd be drooling to work on this box, rather than being stuck with Unix and C or Java and JDBC or .NET and ODBC. It is still a query but far more than Query/400. We are comparing The Enterprise to an old oil burning Chevy. No, you're comparing your CD player with someone else's AM/FM radio. Sure you get better sound, but it won't do you any good if the car doesn't run, and the car of Enterprise computing runs best on RPG. Queries are just not the end-all be-all of IT, and where queries cannot go, RPG is already there. Joe

                Comment


                • #53
                  RPG and DB2: The Future Is Now

                  ** This thread discusses the article: RPG and DB2: The Future Is Now **
                  I did see the benchmark results of Joe's site and the 5.84 seconds for a single fetch does not reconcile with what I have seen in production environments. All I can think is the benchmark ran the program once as previously running a program once to get a record would have been slow, but leaving that program active subsequent calls were subsecond. Actually, the results are based on 10,000 repetitions, so we're talking a single SQL FETCH taking the better part of a millisecond (and the CHAIN taking more like 150 microseconds). I'll have some Java benchmarks out there this week, along with some JDBC. As I said, Java performs adequately, but still much slower than RPG. Preliminary tests, though, show JDBC to be a dog. Joe The IAAI Website

                  Comment


                  • #54
                    RPG and DB2: The Future Is Now

                    ** This thread discusses the article: RPG and DB2: The Future Is Now **
                    Dave400, I don't understand what you mean by this: "Yes, but the reverse is a close description for a java developer." I am not a Java developer. I took a class on it around 2000 or 2001, and was amazed at how complicated it seemed. I hope it has changed by now. I guess the way that you compare current RPG to your first experience with RPG (it's totally different nowadays and not just limited to 6 position variable names and fixed column positions) is the same way I think of Java -- it is based on my first experience of it. But I know RPG has changed significantly. Based on what I learned, and comments from the people I work with, who are involved with Java, not much has changed in the Java world. I have spent time trying to find something to back up my claim about Java on the iSeries. Unfortunately, I cannot quickly locate it. However, the instructor in my Java class said at the time that the AS/400 was the best Java server ever, and that I should be lucky to be working on it. I have seen claims very recently regarding it, but cannot quickly locate them. Maybe someone else reading this column can come to my rescue.

                    Comment


                    • #55
                      RPG and DB2: The Future Is Now

                      ** This thread discusses the article: RPG and DB2: The Future Is Now **
                      Thanks, Doug. Your observations are spot on. Java has a place, as does SQL, in every developer's toolbox. For sure if you use RPG and you write queries, you ought to know SQL. Just like if you plan to have a web interface, you better know Java and JavaServer Pages (there are other web technologies, but few that mesh so well with a tiered architecture where you may or may not run your web interface on the same box where your production data resides). The problem with Java and platform independence rises not so much from the JVM, but from al lthe add-ons. For example, anybody trying to use JDBC in a production environment uses connection pooling, and pooling is a little different on every server (not to mention the issues surrounding security and auditability in a connection pool). Or they ue EJBs, which also require extra configuration, or a third-party persistence tool. None of these are "platform independent" in the same way that Java is. In fact, there's much the same issue surrounding SQL. By definition the machine is deciding what to do, and when the machine decides wrong, you need to tell it the right way. These are the "performance options" SQL developers are so fond of. They are different not just from OS to OS, but from one machine to another depending on the contents of your data files. And so a lot of SQL is trying to figure out which performance tweaks work the best on your machine... for now. Because remember, if your data changes significantly, your SQL performance can go right down the toilet. Don't get me wrong - I know this can happen with RPG as well. But it's a lot easier to identify and fix in an RPG program where I know exactly which files are being accessed when. Anyway, this has been an interesting discussion so far. I'm curious to see where it goes from here! Joe The IAAI Website

                      Comment


                      • #56
                        RPG and DB2: The Future Is Now

                        ** This thread discusses the article: RPG and DB2: The Future Is Now **
                        Actually, the results are based on 10,000 repetitions, so we're talking a single SQL FETCH taking the better part of a millisecond (and the CHAIN taking more like 150 microseconds). I'll have some Java benchmarks out there this week, along with some JDBC. As I said, Java performs adequately, but still much slower than RPG. Preliminary tests, though, show JDBC to be a dog. Thanks for clarifying the SQL performance. I will be interested to observe what you get for JDBC. I glanced at some of our JDBC performance figures on an untuned test server. This is an Oracle 9i DB with XA complianent Data Source. WAS was on a seperate server to the database server. Insert single row was approx 0.008 - 0.010 seconds. Single Row Select at 0.016 -0.020. In my opinion any of these perform sufficiently well for most business requirements. I am not disputing that RPG is faster, I just dont think the gap is sufficient to make it a significant decision criteria. Dave

                        Comment


                        • #57
                          RPG and DB2: The Future Is Now

                          ** This thread discusses the article: RPG and DB2: The Future Is Now **
                          It's good to see the pot stirred by someone else for once. I think the only consensus that will come from this discussion is that the days of an RPG/CL only shop are gone. We have to learn at least SQL and maybe Java in order to stay competitive. --buck

                          Comment


                          • #58
                            RPG and DB2: The Future Is Now

                            ** This thread discusses the article: RPG and DB2: The Future Is Now **
                            I don't understand what you mean by this: "Yes, but the reverse is a close description for a java developer." Sorry, my mind was out of step with the fingers. What I was suggesting is that a java developer who started working on supporting RPG code would probably be faced with a hard task. I suspect a lot of the issues you may have faced were transitional issues. On the performance I seem to recall years back there was an IBM AS/400 Business Object Benchmark, I dont think it is relevant today.

                            Comment

                            Working...
                            X