Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

The iSeries: The Once and Future King

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

  • The iSeries: The Once and Future King

    ** This thread discusses the article: The iSeries: The Once and Future King **
    Doc, I agree with you on #2. Our programming efforts are based upon products supplied by BCD, a third party vendor. However, this is normal in the computing industry. Intel doesn't supply compilers, third party vendors do. Don't take this as a knock, but I think that sometimes a consultant's view of the iSeries world is a bit warped. Often consultants are called into companies that don't have the commitment to the platform to hire employees to do the work. They hire consultants to "get them over the hump" until they can move onto the projects that they have employees available to do the work. I don't use consultants in the iSeries world and hire only permanent programmer employees. We're not a big shop at only 10 iSeries programmers, but we're typical of a stable iSeries environment where we know what we expect of the iSeries and plan our staff accordingly. It is shops like our that consultants would have no experience with. And, believe me, there are TONS of iSeries shops that are staffed entirely by employee-only programmers. chuck Opinions expressed are not necessarily those of my employer. "E Doc" wrote in message news:6b229b3b.14@WebX.WawyahGHajS... > I'm sorry that my previous post was so long. > > My points were actually pretty small, buried under a ton of rubble. To sum > up, here they are: > > 1. IBM has treated the legacy AS/400 codebases as a waste of time and > money for too long. > 2. Other vendors are supplying solutions that meet immediate needs far > better than IBM. Vendors have learned to exploit the gulf that's come up > between the AS/400's users and IT management. > 3. This isn't a case of EVOLUTIONARY v. REVOLUTIONARY. It's a simple case > abandonment by IBM. > > While my criticisim of IBM's new ideas may be too broad with regard to the > industry, I think the counterarguements are two narrow. For example, Joe's > sold his (most excellent) tool to a shop in Wisconsin. However, just > because one shop in Wisconsin is using your product, does not mean that > you're getting full industry exposure either. You have a tool that you're > marketing to AS/400 shops. In other words, the AS/400 is your market. Your > customers are interested in keeping and modernizing their 400's and their > 400 applications. > > Chuck, I work in integrated shops that use the 400 in a variety of ways. > Without exception, all of these shops have had their 400's for at least 10 > years, and most of their systems were migrated to the 400 from the S/38. > Other systems arrived on the scene after the AS/400 became marginalized by > IBM. > > I have yet to see a non-400 shop embrace the AS/400. By "embrace," I mean > "buy a new AS/400 for core business applications". Even in buyout > situations, I've yet to see the 400 become the main system. > > Also, where is the next generation of AS/400 jockies going to come from? > Just curious. IBM doesn't seem to be too interested in that, either. > > Again, I think it's too little, too late. I hope I'm wrong.

    Comment


    • The iSeries: The Once and Future King

      ** This thread discusses the article: The iSeries: The Once and Future King **
      Actually, I wasn't talking about PSC/400, even though it is a most excellent tool. I was just talking about going up and doing a little mentoring on advanced architectures for the iSeries, and watching this company go to town with the concept. As to newly installed iSeries boxes, that's what the whole marketing gig is about. SMBs are the last great space for midrange computers; when a company outgrows Peachtree and Quicken, the next level is a midrange. And while Microsoft would love that midrange to be a server farm, the truth is that C-level executives are starting to recognize that server farms are a bad return on investment. This is the issue that IBM hopes to exploit, and that I believe will lead to a whole bunch of new installs in the next couple of years. As to iSeries programmers, I believe any business application programmer has to be first off a really good programmer, and a really good programmer can change languages as easily as they change their underwear (no comments). So, even if you don't have an RPG savvy kid in college, hire him for the GUI stuff, which every CS101 nerd is pretty much able to do, and if he shows aptitude, then see if he wants to make the leap to REAL programming . Joe

      Comment


      • The iSeries: The Once and Future King

        ** This thread discusses the article: The iSeries: The Once and Future King **
        Joe, Joe said: JSP Model II has many advantages that RPG-CGI simply can't compete with (ranging from security to scalability to flexibility to cost). Can you expand on this? I'd love to know the details. One obvious advantage is being able to extend or implement a java class. RPG can't do that. The April 2005 issue of iSeriesNetwork has 2 articles on RPG-CGI. Chris

        Comment


        • The iSeries: The Once and Future King

          ** This thread discusses the article: The iSeries: The Once and Future King **
          Joe, I'd like to see an expansion of this also. Please place the explanation in the context of how it's REALLY used, not theoretical usages. For example, one would argue that a Plymouth Voyager simply can't compete with a Ferrari. But, in the real world we all drive the same freeways with the same speed limits so even though a Ferrari is a better car it may not be the better choice given constraints and requirements. We have hundreds of CGI programs in production that seem to work just fine. I'd like to know what, in the real world, what I'm not doing that I could have done in Java. chuck Opinions expressed are not necessarily those of my employer. "Chris Ringer" wrote in message news:6b229b3b.18@WebX.WawyahGHajS... > Joe, > > Joe said: JSP Model II has many advantages that RPG-CGI simply can't > compete with (ranging from security to scalability to flexibility to > cost). > > Can you expand on this? I'd love to know the details. One obvious > advantage is being able to extend or implement a java class. RPG can't > do that. The April 2005 issue of iSeriesNetwork has 2 articles on RPG-CGI. > > Chris

          Comment


          • The iSeries: The Once and Future King

            ** This thread discusses the article: The iSeries: The Once and Future King **
            Well, not to go into it to any great degree, but here are a few simple reasons: 1. Security. You can offload the web access to a cheap PC in the DMZ, thus preventing DoS attacks on your priary machine. To do this with RPG-CGI would require a second iSeries. 2. Scalability. Java supports multi-threading. RPG does not. As your workload grows, synchronization costs in RPG can get quite high. Also, JSPs are compiled classes and RPG-CGI requires constant re-interpretation of templates. This cost gets dramatic as your number of users increases. 3. Flexibility. Changing a logo on a JSP is as quick as editing a text file. You may be able to do that in RPG, but it requires updating a template file with whatever non-standard template language is being used. And if the templates are pre-parsed for performance, you need to somehow let the server know a template has changed. 4. Cost. If cost is truly your issue, you can completely offload the web serving to a cheap (under $1000) Unix box, while keeping your business logic on the iSeries. These are just a few of the reasons for using JSP. You've mentioned the extensibility through Java classes; Java is also very good at calling RPG, while the reverse is not always true. Java can also more easily access resources on other machines in the network. The only valid reason to NOT use JSP, in fact, is if you don't have any Java skills in house. And I've been saying over and over that a thin Java veneer is all that is necessary to get a good, solid application architecture in place. All your business logic and application logic can stay in RPG, just the UI is in Java. It's truly the best of both worlds. Joe

            Comment


            • The iSeries: The Once and Future King

              ** This thread discusses the article: The iSeries: The Once and Future King **
              Chuck, as far as I know, you don't program CGI. You use a tool. So right off the bat, we have the licensing costs for the tool. How much are you paying for that? Second, you can't offload your CGI programs. This affects security, scalability and cost. Third, you cannot write and call Java methods. This simple capability allows you to do all kinds of custom formatting routines, write them once, and use them throughout your system. There are just a few. I'm not going to argue the merits of your decision. In the end, it's a business decision. But all things being equal, the JSP/servlet architecture is far more technologically advanced than RPG-CGI. Joe

              Comment


              • The iSeries: The Once and Future King

                ** This thread discusses the article: The iSeries: The Once and Future King **
                Joe Pluta said the following on 3/29/2005 4:22 PM: > But all things being equal, the JSP/servlet architecture > is far more technologically advanced than RPG-CGI. Hi Joe! First, I agree with you. Second, having fought this battle and lost, I can tell you that pushing technology alone can be a frustrating experience. Without a real-world example of what JSP II brings to the table, I couldn't sell Java/JSP. Heck, I couldn't sell CGI either and for the same reason. The biggest problem for a green screener like me is that I haven't got instant command of a suite of JSP-enabled front end business solutions ready to pull out of my hat. On the other hand, I have a TON of RPG procs and snippets that I dazzle people (OK, maybe not dazzle) with routinely. I don't think there's a good answer for that dilemma. Without examples, there isn't a demonstrable reason to have a management push in favour of new tech. Without new tech, we can't really deliver web-enabled apps. And that's where the tools people make their living. --buck

                Comment


                • The iSeries: The Once and Future King

                  ** This thread discusses the article: The iSeries: The Once and Future King **
                  Joe, Thanks for the reply. You asked: "You use a tool. So right off the bat, we have the licensing costs for the tool. How much are you paying for that?" It cost about $12k. Considerably less than the cost to train 10 programmers in Java. Joe said: "Second, you can't offload your CGI programs. This affects security, scalability and cost." I'm not sure what you mean by offloading CGI programs. Can you explain further? Joe said: "Changing a logo on a JSP is as quick as editing a text file." Same with us. I don't see any difference here. I can change a style sheet and/or an "include" and the logo is changed. Joe said: "Third, you cannot write and call Java methods. This simple capability allows you to do all kinds of custom formatting routines, write them once, and use them throughout your system." The "tool" we use allows us to create custom functions that are stored as procedures on the iSeries and can be called as often as we like. I don't know what Java methods are so maybe I'm not missing anything? Joe said: "There are just a few. I'm not going to argue the merits of your decision. In the end, it's a business decision. But all things being equal, the JSP/servlet architecture is far more technologically advanced than RPG-CGI." We agree. I'm all for getting solutions in place. With existing staff. Java doesn't offer that, the tool I chose does. With our purchased tool a programmers are productive with 4 hours of training and can be doing very complex tasks with less than 1 month of using the tool. Everything I've seen about Java tells me that programmers that have never programmed in anything but RPG their entire career will not be so productive so soon. As for scaling, I won't have a problem with that since we only deploy AS/400 related web pages to our WAN, they never see the Internet. All of our Internet development is done in C# using IIS and that seems to scale enough for our purposes. chuck Opinions expressed are not necessarily those of my employer.

                  Comment


                  • The iSeries: The Once and Future King

                    ** This thread discusses the article: The iSeries: The Once and Future King **
                    Chuck and Buck, you both miss the point entirely. I am recommending a mixed language approach: a thin veneer of Java over an RPG infrastructure. Chuck, where do you get "ten Java programmers"? It's random numbers like this that make it difficult to talk to you. A properly designed JSP/servlet solution can be just as cost-effective as your tool, yet more flexible (and secure and scalable, and la de dah), using a single Java guy, and not even an expert at that. I have a client doing JSP/servlet with TWO programmers (total!) in Wisconsin, and they love it. They're churning out code. Yes, you need one person with enough Java to maintain the infrastructure, but it ain't that much. In any case, this argument is pretty useless to anybody else, Chuck. You're not talking about CGI, you're talking about your vendor's tool, and since your vendor advertises with MC, that's a no-win for me. On the other hand, your vendor aside, I see you have RPG for your intranet and C# for your Internet, and I just shake my head. You could be using the same interface for both pieces and gaining hugely on economies of scale, not to mention the ability to use a single mechanism to secure intra-, extra- and Internet users. But according to you, not one of your guys can learn Java. Given that pool, you probably should buy a tool that insulates them. Finally, "offloading" is a pretty standard term. It means running on a different box. Any Java code can be run on another box, but your CGI programs MUST run on an iSeries. If you don't understand that, you have a LOT of basic research to do. Joe

                    Comment


                    • The iSeries: The Once and Future King

                      ** This thread discusses the article: The iSeries: The Once and Future King **
                      Buck, I hope I was able to make clear in my posts that I don't think you should have all-Java. I get hoarse saying the same thing over and over again, but the best solution is a mixed-language architecture, with the percentages dictated by business issues like staff talent and long-term objectives. But, in my time working with many different architectures, it's become clear to me that a JSP/servlet architecture for the UI which then delegates to an RPG infrastructure for business logic is by far the best solution, and is most easily implemented by most companies. At the beginning, you only need one or two Java guys, and they don't need to be experts. They simply need to know enough to maintain a simple infrastructure designed to pass data between the RPG back end and the JSPs. In effect, you end up using your JSPs as sort of "super display files". ANYBODY can learn this. Anybody. If you have ten programmers and none of them can pick up the Java required for this, then you've got bigger problems coming up down the road than just the UI approach to take. So, the BIG advantage is that you can use all of your RPG snippets, AS WELL AS the Java classes you learn along the way. Joe

                      Comment


                      • The iSeries: The Once and Future King

                        ** This thread discusses the article: The iSeries: The Once and Future King **
                        Joe said: "using a single Java guy, and not even an expert at that." As a manager I never use any tools or applications that are only known by a "single guy." That leads to a single point of failure. It would take at least 4 or so before I'm comfortable. Programs have a tendancy to break down when the "single guy" is in Maui and his backup is at COMMON. The best scenario is that every programmer on my staff know every tool. That isn't always the case but it's never just 1 or 2. Joe said: "I have a client doing JSP/servlet with TWO programmers (total!) in Wisconsin, and they love it. They're churning out code." Every shop is different. Nearby Countrywide has over 500 AS400 developers. Would you suggest that they the Wisconsin duo could churn out as much as Countrywide? Certainly not. So, I'm not sure what your example shows. As I said before every shop is different. Clearly you can't have any concept of what my programmers "churn out" and what their workload is like. Joe said: "In any case, this argument is pretty useless to anybody else, Chuck. You're not talking about CGI, you're talking about your vendor's tool" I would propose the argument whether we're talking about Java or WebSmart that we are ALL talking about tools. It's just a matter of which tool and which vendor you choose. Are you suggesting that if a tool comes from IBM it's somehow not a tool? Joe said: "On the other hand, your vendor aside, I see you have RPG for your intranet and C# for your Internet, and I just shake my head. You could be using the same interface for both pieces and gaining hugely on economies of scale, not to mention the ability to use a single mechanism to secure intra-, extra- and Internet users." Ah, if only the real world were as simple as the theoretical world. Joe said: "But according to you, not one of your guys can learn Java." That's Joe's interpretation of what I said, not the wording I used. Joe said: "Finally, "offloading" is a pretty standard term. It means running on a different box. Any Java code can be run on another box, but your CGI programs MUST run on an iSeries." And I thought you were up on the latest technology. Haven't you heard the holy grail? Consolidation is the latest buzword to hit the streets. It's right up there with Java! If you don't understand that you haven't been reading Midrange Press! ;-) chuck Opinions expressed are not necessarily those of my employer.

                        Comment

                        Working...
                        X