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

  • #31
    The iSeries: The Once and Future King

    I don't think there's anything to find fault with in any event. But that aside, does CGI require the memory of Java for JSP? No, we all know it could be written in C as far as that goes. The job overhead? I have a pending question about that, but I thought I saw many moons ago something about CGI job overhead being taken care of by IBM. I don't know. That's why I'm asking. But it's hard to believe that a job is still spawned for CGI to create a web page, unless IBM just deliberately wants to cripple non-Java Websphere SQL solutions, which I wouldn't put past the dudes in Armonk. We all know the Sys/3X only exists as it is because Rochester told Armonk they were building an accounting machine. As for DoS, it would seem to me to be brain dead to have socket code that is allowed to tie up the AS/400 responding to DoS attacks. Sure, it will deny service of legitimate web accesses mixed in there, but the job allocation for servicing sockets ports should just dwindle until the attack dissipates. I do understand the "we don't want our crown jewell exposed to the internet" thinking, sorta, as far as port 80 goes I guess is what they have in mind. Still, it should be a smaller AS/400 with DDM communications to the crown jewell AS/400's, although only an OS/400 knowledgeable person will believe that. I think PC's are used because web people in most corporations are not AS/400 people and they require their OS to run on a PC, not because the PC is cheap. That's just an excuse that justifies corporate behavior in deference to their web people who don't give a rat's behind for the AS/400 and how OS/400 can kick their butts six ways to Sunday. For that matter, IBM doesn't have a clue about it either. Just look at their i5 ads. They really think they're going to sell i5's to consolidate those cheap PC's from those people I was talking about. Give me a break. It's integration within OS/400, not outside of OS/400, that sells the AS/400. But only Rochester would know that. rd

    Comment


    • #32
      The iSeries: The Once and Future King

      Sure, it will deny service of legitimate web accesses mixed in there, but the job allocation for servicing sockets ports should just dwindle until the attack dissipates. What makes you think this, Ralph? What feature in the operating system controls this "dwindle factor"? The only thing I know of for sure is that when a job hits timeslice end it will be knocked down a microstep in priority, but this isn't a regular job in a CPU loop. This is the overhead associated with lots and lots of hardware interrupts. Interrupts tend to run at a very high system priority (it's the nature of interrupt processing) and so an overflow of spurious interrupts can indeed shut down processing of any machine. Joe

      Comment


      • #33
        The iSeries: The Once and Future King

        By the way, in case I wasn't clear about this, JSP Model II is the sderver-side technology used to both generate a browser UI and handle user responses. The browser renders the data sent to it, which is generated by the JSP. In my simple world, the data to be rendered consists of HTML, CSS and JavaScript, along with the occasional image. That being said, I believe JSP Model II is architecturally superior to RPG-CGI, for the reasons I've stated. Joe

        Comment


        • #34
          The iSeries: The Once and Future King

          Joe, What you have described, in terms of the JSP model vs CGI, does not provide any clear technological distinction or advantage. CGI on the iSeries does exactly what you describe JSP as doing- it's just that. generally, the development methodology is much easier with CGI. I'm glad to see you state 'you believe' - that's a much fairer statement than asserting your claims as fact. Duncan

          Comment


          • #35
            The iSeries: The Once and Future King

            Duncan, I went through in great detail why JSP is better than RPG-CGI. It can be moved off the machine, it uses a standard tag set, and so on. It does indeed provide several clear technological advantages. As to your asertion that generally the development methodology is much easier with CGI, that's simply not true. With WDSC I can test the entire JSP -- includign setting breakpoints in the JSP itself! -- on my PC. Try that with RPG-CGI! Joe

            Comment


            • #36
              The iSeries: The Once and Future King

              I suppose we could keep going back and forth like this for quite a while. I'd just like to address your last set of comments. 1. I understand your initial comparison was RPG-CGI to JSP, and not product-specific. I don't want to drag WebSmart into the discussion, either - Chuck is already a great advocate of it, and has noted it generates CGI-protocol compliant as well as JSP-based applications. I do hope, however, that you will take the opportunity to look at WebSmart some time. I'm pleased to see you've looked at Nathan Andelin's work. It would be nice, as an industry expert, for you to take a detailed look at a more prominent product in the marketplace (if you've already done so, my apologies). I was trying to expand the discussion somewhat by referring to 'ILE CGI' versus 'RPG CGI' - for reasons I've already mentioned. However, I'm willing to confine my responses to your original playing field. Security: I agree with you (as you can see from an earlier post I wrote before reading your last one) that a dedicated firewall/web applicance is useful. I don't see how this affects running JSP versus CGI though - I'd have such a device even if I was serving pages from a Unix box using JSP or PHP or whatever. Scaleability: First, it is not quite accurate to say each CGI requires a new job. And, Ralph- you might want to read this- this answers some of your questions too. The web server (Apache or Original) has a main helper job that farms off requests to other jobs running in the HTTP subsystem. These other jobs behave like Unix daemons - they remain open for as long as the subsystem is running. CGI Web page requests come in and out of these jobs as necessary, with the helper job queuing up requests if the number of simultaneous requests exceeds the number of currently available open jobs. So it is not correct to say that a new job is opened up every time a page request comes in. You can optimize the number of open jobs when you start the web server instance. We usually have just 5 running, and that serves us fine (pun intended) - although we probably don't have as much traffic as many of our clients. However, they usually find that 10 jobs at the most is adequate. These are 'passive' jobs - meaning they take up no processor resources unless something is actually running in them. So 10 jobs can serve literally thousands of requests an hour. Because of the demands of WebSphere, and because of IBM's marketing push of WebSphere (until recently!) IBM has done a good job of keeping quiet about just how successful their HTTP/CGI team has been at getting incredible performance with miminal impact on system resources. We literally have many clients running AS/400 270's as web servers - something that is impossible from a practical standpoint with WebSphere (although, admittedly, Tomcat isn't so resource-intensive)! While it is true that Java pages are threaded, there is incredible initial overhead to load the WebSphere web server in order to provide the benefits of threading. If we are talking about huge enterprise-level i5's, this initial overhead is probably (I'm guessing here) not significant. But for most SMB's (or small departments of large corps) with small AS/400's -iSeries-i5's the overhead is completely impractical. Just go through IBM's hardware sizing wizard and look at their recommendations for WebSphere to see what I mean. I realize this may not be the case on other platforms (or web servers, such as Tomcat), but I think we all agree that the benefits of the i5 far outweigh the benefits of other platforms - at least that's the context for my thinking and my business model. We've also written a program called 'loadtester' that automatically submits x number of real requests for a given CGI program (it's not something we distribute without extreme discretion, because in the wrong hands it could be used for DOS attacks). We use it to simulate thousands of users hitting a web site, at varying intervals (which we can set). We've done this for skeptical clients who don't believe our claims of scaleability. In every case, both we and the client have been pleasantly surprised. I don't believe we've ever had a case where someone said the results of the simulation indicated inadequate performance. Flexibility: while there may be more 'standards' for JSP, I doubt one would write JSP's without some sort of development tool from a third-party vendor. One of the points someone else made in this discussion was about 'build or buy'. I have always been an advocate of leveraging our developer's intelligence by minimizing the hand-coding they have to do and making them as productive as possible. I'm sure you'd feel the same way, Joe. In which case- your point is really about availability of information on JSP versus CGI, not technological superiority. The term 'standards' is also open to interpretation. One of the reasons Java has not yet met its potential (and believe me, I'd love it to - I love the idea of write once, run anywhere) - is that the reality is: write once, test everywhere - JVM's are just not consistent. This was one of the major reasons Java applets failed for general business use. BTW- I am not a fan of CGIDEV/2. I think it encourages inconsistent coding practices and cultivates a 'let's just code it by hand' mentality that flies in the face of modern application development practise and modern law (SOX). It's fine as a primer on the subject, but woefully inadequate as the basis for a robust, controlled development environment. A couple of other points - I believe 'server side includes' are a web server construct, not dependent on the underlying CGI implementation. In other words, you embed a 'standard' tag for SSI in your script that the web server either recognizes or doesn't (depending on whether you've turned on support for SSI). I don't like SSI's at the web server level simply because it slows performance - the web server has to parse all the HTML before delivering to the client in order to determine if an embedded SSI directive exists that must be executed. A better approach is to use 'standard' i5 API calls to IFS routines to include files. Again, many people have written and published such routines for the iSeries etc. Cost: I think you've helped make my point here. Many small AS/400s (270's etc.) can run CGI no problem. They cannot run JSP. That latter fact doesn't seem a compelling reason to me to try to run a Unix web server. Again, this is a TCO argument. We may have problems getting developers to learn Java, but it's probably nothing compared to the headaches of getting AS/400 Sysops to run Unix boxes! Java does run better on PC's than AS/400's - but Java on PC's does not run better than CGI on AS/400's- taking into account AS/400 security, reliability, ya di ya di ya... One last point on this statement: "but more importantly BCD advertises with MCPress and I'd rather not try to find fault with an advertiser. " I'd like to go on record as saying that the AS/400 press in general has assiduously avoided favoritism towards vendors based on their advertising arrangements. I think this is a testimony to the integrity of the various publications. Ironically, it is often a source of great frustration to our marketing team that this is so. We receive no special favors even though we spend considerable amounts of money with several publications. However, perhaps a more legitimate source of frustration is the apparent lack of willingness on the part of some members of the press and editorial teams to objectively and comprehensively examine the offerings of third party vendors. We have often encouraged senior editorial staff to contact us to have objective, technical reviews of our products. I feel strongly that many writers (and not just you, Joe) have been overly enamored with the WebSphere /Java technological superiority argument that IBM has so successfully marketed to the detriment of their readership. A considered examination of the alternative SOLUTIONS (not 'technologies') provided by vendors such as BCD by respected names in the industry such as yourself would enhance the image of the i5, IBM, the vendors in this marketplace, and all of us - developers and users- who believe so strongly in the superiority of the i5 hardware/software platform over Unix and Wintel. Regards, Duncan

              Comment


              • #37
                The iSeries: The Once and Future King

                Ralph, I've written a post later on in response to Joe that discusses the scaleability debate over CGI. It describes technically how the web server works. It's not quite accurate to say a new job is spawned every time - I explain why there. Regards, Duncan

                Comment


                • #38
                  The iSeries: The Once and Future King

                  Ralph, Sorry I haven't answered directly - please read my post in response to Joe's comments for a description of our experiences with CGI, and a technical outline of how CGI jobs are handled. Duncan

                  Comment


                  • #39
                    The iSeries: The Once and Future King

                    Wow! Joe! You are up early! It must be 5 am your time. And, I notice you mention WDSc - so in this case you are referring to the TOOL you use, not really JSP per se (which can be written by hand - like RPG-CGI a la CGIDEV2). And - debugging is possible with RPG-CGI, too (from green-screen, even!) And - some tools do have debugging facilities! (ok - that's 4 responses). Duncan

                    Comment


                    • #40
                      The iSeries: The Once and Future King

                      Okay, now we're going to get into some disagreement, Duncan. Let's start... I'd have such a device even if I was serving pages from a Unix box using JSP or PHP or whatever. But the point is that you CANNOT have a firewall device when running RPG-CGI unless that firewall is another iSeries. CGI Web page requests come in and out of these jobs as necessary, with the helper job queuing up requests if the number of simultaneous requests exceeds the number of currently available open jobs. So it is not correct to say that a new job is opened up every time a page request comes in. You can optimize the number of open jobs when you start the web server instance. We usually have just 5 running, and that serves us fine (pun intended) - although we probably don't have as much traffic as many of our clients. However, they usually find that 10 jobs at the most is adequate. Okay, I'll need more education here. I have 20 people doing order entry simultaneously. They all need persistent connections, since this is an order entry application with lots of temporary data. How many CGI jobs do I need for this? If I only need five, where is the persistent session data stored? How is it saved? How is it restored? How do you keep files open between calls? We literally have many clients running AS/400 270's as web servers - something that is impossible from a practical standpoint with WebSphere (although, admittedly, Tomcat isn't so resource-intensive)! Okay, now you're simply incorrect. Feel free to go to http://www.plutbrothers.com at any time. This website runs entirely on a TINY little 370 CPW model 270, and was built completely using nothing but WDSC. There are lots of people running WebSphere on a model 270. I don't know where you get your information, but it's way wrong. We've also written a program called 'loadtester' that automatically submits x number of real requests for a given CGI program (it's not something we distribute without extreme discretion, because in the wrong hands it could be used for DOS attacks). I use a product called Web Roller. Wonderful product, lets you build scripts, even use data sent to you in your response (really important for session testing). Again, though, we need to be sure what the jobs are doing. That's why I try to separate online transaction processing programs from data query. I'm still waiting to see how you get 20 persistent session from 5 jobs. while there may be more 'standards' for JSP, I doubt one would write JSP's without some sort of development tool from a third-party vendor. It depends on what you mean by tool. An IDE such as the JDT in WDSC is fine (and indeed, almost mandatory). A code generator such as the web service wizard in WDSC is not acceptable, because I wouldn't use the generated code in production. I believe in IDEs, I do not believe in code generators. One of the points someone else made in this discussion was about 'build or buy'. I have always been an advocate of leveraging our developer's intelligence by minimizing the hand-coding they have to do and making them as productive as possible. I'm sure you'd feel the same way, Joe. It depends. I absolutely abhor using application code generated by a "wizard" or a "4GL". I prefer that developers become productive by writing code once and encapsulating it, using the many capabilities of OS/400 to do so, such as data queues, batch jobs, service programs, and the like. One of the reasons Java has not yet met its potential (and believe me, I'd love it to - I love the idea of write once, run anywhere) - is that the reality is: write once, test everywhere - JVM's are just not consistent. This was one of the major reasons Java applets failed for general business use. I absolutely disagree. JVMs are completely consistent. Please name an instance where, for example, Sun's JDK1.4 differs from IBM's JDK 1.4. Application servers tend to differ, which is why you need to be careful not to use vendor extensions, but that's pretty easy to do. Programs converted by PSC/400 run under Tomcat just as well as they do under WebSphere. I feel strongly that many writers (and not just you, Joe) have been overly enamored with the WebSphere /Java technological superiority argument that IBM has so successfully marketed to the detriment of their readership. A considered examination of the alternative SOLUTIONS (not 'technologies') provided by vendors such as BCD by respected names in the industry such as yourself would enhance the image of the i5, IBM, the vendors in this marketplace, and all of us - developers and users- who believe so strongly in the superiority of the i5 hardware/software platform over Unix and Wintel. Duncan, if you'd like to continue this conversation, you need to quickly dial down the rhetoric. I am not "overly enamored" of Java, I am an advocate of JSP Model II as the best browser interface for the iSeries. IBM did not market this technology to me, Sun did. I've been coding Java for nearly 10 years now, long before IBM got into the game. In fact, I taught this architecture TO IBM in Israel around the turn of the century. So, I'd really appreciate it if you give me a little more respect than calling me an "enamored writer". As to the superiority of the IBM platform, did you even read the article? Have you read anything I've ever written? I am perhaps the most ardent advocate of the iSeries writing today. Not only that, I am stridently opposed to converting RPG code to Java, and I insist that RPG is the best language available for writing business logic. It is, however, less suited to static problem sets like HTML generation. OO languages flourish in environments where the rules rarely change; that's where you can really take advantage of the rigid typing and hierarchical nature of Java. Anyway, you've made some points, but some have started to veer away from the technical and into the realm of opinions. And of course, you've continued to mention WebSmart, which is not the focus of this discussion. I'll wait for our specific technical answers to my comments, though, and see if we can keep this conversation on topic. Joe

                      Comment


                      • #41
                        The iSeries: The Once and Future King

                        Up early? HAH! With a 13-month old, this is late . Actually, not really, but he's battling an infection so he's a bit distraught these last few days. I feel a lot is getting lost in the translation here, Duncan. An IDE is different from a code generator, as I hope I've made clear. IDE = GOOD, CODE GENERATOR = BAD. As to the debugging, with WDSC I can put a breakpoint right in the JSP. Can't do that with RPG-CGI. Maybe with your tool, but I continue to firmly insist that vendor tools are not part of this discussion. Joe

                        Comment


                        • #42
                          The iSeries: The Once and Future King

                          But the point is that you CANNOT have a firewall device when running RPG-CGI unless that firewall is another iSeries. I don't understand your point here. We DO have a firewall device, between the outside world and iSeries, AND we are running RPG-CGI !! We also have a DNS server, etc. This is simple network topology. Okay, I'll need more education here. I have 20 people doing order entry simultaneously. They all need persistent connections, since this is an order entry application with lots of temporary data. How many CGI jobs do I need for this? If I only need five, where is the persistent session data stored? How is it saved? How is it restored? How do you keep files open between calls? Ok- I'll educate you. It's done using session ids - a method used by Coldfusion, ASP, PHP and any CGI programming method. You've seen them at many commercial sites (such as Amazon and Yahoo) that you visit. They usually are identified with a parameter called SID. We call them by some other parm name (doesn't matter). You simply pass this unique id back and forth in the url's, thus accomplishing persistence. This is 'standard' technology. There are optimization techniques you can use, depending on the application, to manage file opens/closes. Okay, now you're simply incorrect. Feel free to go to http://www.plutbrothers.com at any time. This website runs entirely on a TINY little 370 CPW model 270, and was built completely using nothing but WDSC. There are lots of people running WebSphere on a model 270. I don't know where you get your information, but it's way wrong. I apologize - this is the first time I've heard of this. Are you running the full WAS, or WAS express? BTW - if you are keeping product names out of it, let's keep yours out of it too. I use a product called Web Roller. Wonderful product, lets you build scripts, even use data sent to you in your response (really important for session testing). Again, though, we need to be sure what the jobs are doing. That's why I try to separate online transaction processing programs from data query. I'm still waiting to see how you get 20 persistent session from 5 jobs Our load tester does the same thing. Same thing with sending data in the response. As I mentioned before, we handle online transaction processing the way I described, with session id's. We have customers who banks, insurance companies, multinational music companies with online transaction processing using this technique. I believe in IDEs, I do not believe in code generators. Not sure what your intention is by this statement, but I have a suspicion. Hope I'm wrong. And, FWIW - I'm not discussing 'code generators' I absolutely disagree.JVMs are completely consistent. Please name an instance where, for example, Sun's JDK1.4 differs from IBM's JDK 1.4. Application servers tend to differ, which is why you need to be careful not to use vendor extensions, but that's pretty easy to do. Programs converted by PSC/400 run under Tomcat just as well as they do under WebSphere. Ok- feel free to disagree. I'll be interested to see what other readers think of my point. Also - you've mentioned your (non-competing) product again. Duncan, if you'd like to continue this conversation, you need to quickly dial down the rhetoric. I am not "overly enamored" of Java, I am an advocate of JSP Model II as the best browser interface for the iSeries. IBM did not market this technology to me, Sun did. I've been coding Java for nearly 10 years now, long before IBM got into the game. In fact, I taught this architecture TO IBM in Israel around the turn of the century. So, I'd really appreciate it if you give me a little more respect than calling me an "enamored writer". I don't see anything too strong about the term 'enamored' - especially in light of your responses which make such bold assertions as 'JSP is the best technology'. Can you confirm if you have given products like WebSmart as much investigation as you have certain Java products? If not, I rest my case. Also, my company has just as much experience with Java as you do. We had a commercial iSeries Java product in 1998. In fact, we produce JSP applications with our tool! It's your basic premise that JSP is 'superior' to RPG-CGI on the i5 that we are debating here. As to the superiority of the IBM platform, did you even read the article? Have you read anything I've ever written? I am perhaps the most ardent advocate of the iSeries writing today. Not only that, I am stridently opposed to converting RPG code to Java, and I insist that RPG is the best language available for writing business logic. I have read a considerable amount of what you have written. Have you ever 'read' any code I have written? Or any articles I have written? Or reviewed my products (I've been writing S/38 - i5 commercial software since 1982, and, like you, started on a S/3 - in 1977). You may be stridently opposed to converting RPG to Java, but you _have_ advocated using another platform other than the iSeries in this discussion, even if only for testing. I've advocated doing everything on the iSeries. I see this as an inconsistency on your part. It is, however, less suited to static problem sets like HTML generation. OO languages flourish in environments where the rules rarely change; that's where you can really take advantage of the rigid typing and hierarchical nature of Java. I just don't see your point here. I do not see whether a language is strongly typed like Java or loosely typed like Javascript has to do with anything web related. Java can generate HTML, so can Javascript. Anyway, our (not_to_be_mentioned) language has strong typing, and is used to write web applications. If this confuses you, think of it this way: when you write Java, it gets compiled to bytecode that runs in the JVM. When you write RPG, it gets compiled into MI code (or intermediate code - Paul Conte would know better than me) that runs on the OS/400 vertical microcode. When you write in our language, it gets converted to an intermediate step that happens to be a combo of RPG and calls to ILE functions, which then ends up as MI code. So really the 'RPG' bit of it is a red herring. I realize this is off-topic, but I think you've sort of started another discussion by bringing strong/loose typing of languages. BTW- ever heard of functional languages, such as Haskell? And of course, you've continued to mention WebSmart, which is not the focus of this discussion. I'll wait for our specific technical answers to my comments, though, and see if we can keep this conversation on topic. Not sure where I mentioned WebSmart - I believe you brought it up in your comments about us not being competitors and in your implication that you were somehow going easy on me because I'm a vendor who advertises for one of the companies you work for. Clearly that's no longer the case! (you going easy on me, I mean.) Anyway, hopefully I've addressed your technical comments. Regards, Duncan

                          Comment


                          • #43
                            The iSeries: The Once and Future King

                            Okay, now you're simply incorrect. Feel free to go to http://www.plutbrothers.com at any time. This website runs entirely on a TINY little 370 CPW model 270, and was built completely using nothing but WDSC. There are lots of people running WebSphere on a model 270. I don't know where you get your information, but it's way wrong. Joe, I've just been to your site- hadn't been there in a while, must admit, although I do like to keep up with what the competition is doing. It appears most of your pages are static HTML, not requiring any JSP at all. Your demo app (the trains one) is apparently JSP - but it's a pretty small data set, with small pages being delivered. I also doubt that any enterprise would be willing to run their mission-critical businesses on WebSphere Express- but that's possibly just my ignorance. My understanding, though, is that the benefits of scaleability that are much-touted (SQL pooling, threading, etc.) are only supported in the full implementation of the WebSphere WAS- which wouldn't run on your tiny AS/400. Meanwhile, we have clients quite happily running scaleable apps in CGI - without having to buy WebSphere from IBM and without having to do massive hardware upgrades. BTW - I'd say we are in competition. Even though our products use different technological implementations, we are competing for the same mindshare. I respectfully ask: have you ever considered that this puts you in a tenuous position regarding your objectivity as a writer? At the very least, it seems to me you should give serious consideration to revising your mini-bio that appears at the end of your articles, since this is in effect a free advertisement for your products (IMHO). I'll end this post with a sample of what I'd love to put on every post I write: Respectfully, Duncan Duncan Kenzie is the founder and chief architect of ExcelSystems Software Development Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Duncan has used ILE extensively, especially as the base for ProGen Plus, a highly successful iSeries Application Generator and ProGen WebSmart, the only product that can deploy legacy and new systems to the Web as CGIs or JSPs. Duncan is also the author of several technical articles on the iSeries and is a speaker at COMMON. You can reach him at duncan@excelsystems.com

                            Comment


                            • #44
                              The iSeries: The Once and Future King

                              I don't understand your point here. We DO have a firewall device, between the outside world and iSeries, AND we are running RPG-CGI !! We also have a DNS server, etc. This is simple network topology. Let's see if I can explain this. Even with your firewall, port 80 of your iSeries is open to the Internet (through the firewall), and thus is available for a DoS attack. By offloading the web service to an attached appliance such as a Unix box, only the Unix box is exposed to the Internet; the production iSeries has NO OUTSIDE CONNECTION. Is this clear? I'll educate you. It's done using session ids - a method used by Coldfusion, ASP, PHP and any CGI programming method. You've seen them at many commercial sites (such as Amazon and Yahoo) that you visit. They usually are identified with a parameter called SID. We call them by some other parm name (doesn't matter). You simply pass this unique id back and forth in the url's, thus accomplishing persistence. This is 'standard' technology. Yeah, it's standard stateless technology. However, if you've got an order entry program that accesses 30 files, then you need to open all 30 files for every request (not to mention loading and storing all the temporary data). That's why I keep saying, over and over again, that the technology required depends on the application. Simple queries where you're reading a bunch of data from a couple of files is no big deal. Transaction processing where you validate against dozens of different files is a different story. This is where the scalability issue comes into play. Persistence overhead can add up quickly. BTW - if you are keeping product names out of it, let's keep yours out of it too. I mentioned my COMPANY WEBSITE, Duncan. And at that I got it wrong: it's http://www.plutabrothers.com. That's once in some 20 posts, in direct response to your incorrect and misleading statement. As they'd say in Law and Order, you opened up the door, counselor. Ok- feel free to disagree. I'll be interested to see what other readers think of my point. Unacceptable. On challenge, either back up your point or retract it. I'm saying you are absolutely wrong, and guilty of spreading FUD. Also - you've mentioned your (non-competing) product again. Oh go soak your head. I've been quite careful to avoid mentioning PSC/400 or what it does, but if you keep complaining about it, I'll keep mentioning it. I don't see anything too strong about the term 'enamored' - especially in light of your responses which make such bold assertions as 'JSP is the best technology'. And I do, especially with the assertion that it was due to IBM marketing. My advocacy of JSP Model II is based on over 25 years of architecture experience, at the highest levels of the midrange market. Can you confirm if you have given products like WebSmart as much investigation as you have certain Java products? If not, I rest my case. There is no case. Java is not a product, it's a technology. RPG-CGI is a technology. WebSmart is a product. I'm comparing technologies, and I'll say it again: JSP Model II beats RPG-CGI hands down in multiple areas. Also, my company has just as much experience with Java as you do. In fact, we produce JSP application! It's your basic premise that JSP is 'superior' to RPG-CGI on the i5 that we are debating here. Actually, based on your comments (such as the completely misleading comments about running on a model 270, or the incorrect statement that JVMs run very differently on different platforms), it's clear to me that you don't have a lot of Java experience, especially on the iSeries. If you are indeed selling Java expertise, I assume others in your company are better informed. I have read a considerable amount of what you have written. Have you ever 'read' any code I have written? Or any articles I have written? I've never seen a single article published by you that didn't have "WebSmart" in it. You may be stridently opposed to converting RPG to Java, but you _have_ advocated using another platform other than the iSeries in this discussion, even if only for testing. I've advocated doing everything on the iSeries. I see this as an inconsistency on your part. Actually, Duncan, I have and always will advocate using the best tool for the job. I personally believe that all things being equal the best architecture is JSP Model II running on WebSphere Express on the iSeries using RPG as the application controller and the business logic server. However, based on constraints such as machine capacity, security or other concerns, there are times when offloading the web serving workload is a necessity; that requirement alone makes RPG-CGI a bad decision. On the other hand, for shops which cannot or will not ever consider doing anything in Java, RPG-CGI is a reasonable alternative. In those cases, vendor tools such as yours may be a benefit. iI just don't see your point here. I do not see whether a language is strongly typed like Java or loosely typed like Javascript has to do with anything web related. Actually JavaScript is reasonably good for HTML generation, since it's an OO language. The interpreted nature and loose typing allows some interesting capabilities, but makes it more difficult to debug. But either one beats RPG hands down for string generation. Anyway, our (not_to_be_mentioned) language has strong typing, but you apparently dismiss that as inferior technology. I do not have enough information to appropriately judge the technology of your tool. Not sure where I mentioned WebSmart Oh please. "Solutions provided by vendors such as BCD." I suppose you meant their Mahjongg package. Joe

                              Comment


                              • #45
                                The iSeries: The Once and Future King

                                Joe, I've just been to your site- hadn't been there in a while, must admit, although I do like to keep up with what the competition is doing. It appears most of your pages are static HTML, not requiring any JSP at all. They're still being served via WebSphere, which you said specifically could not run a model 270. Your demo app (the trains one) is apparently JSP - but it's a pretty small data set, with small pages being delivered. I also do pilots for all my prospects from this machine. I run all of my PSC/400 demonstrations through this box, and it runs just fine, thank you. As to small pages being delivered, that's what is SUPPOSED to happen in a web application . I also doubt that any enterprise would be willing to run their mission-critical businesses on WebSphere Express- but that's possibly just my ignorance. Many companies run WebSphere Express. But this sort of statement is clearly beginning to show your stripes. You're here to bash WebSphere, and me, and my product, and my company. My understanding, though, is that the benefits of scaleability that are much-touted (SQL pooling, threading, etc.) are only supported in the full implementation of the WebSphere WAS- which wouldn't run on your tiny AS/400. I suggest you get your facts straight. SQL pooling is not a scalability concern (unless you use JDBC, which I do not recommend), and threading is definitely part of any version of WebSphere. What actually do you know about Java and J2EE? BTW - I'd say we are in competition. Even though our products use different technological implementations, we are competing for the same mindshare. Here we go. It's all because you think I'm a competitor. Honestly, dude, we're completely different. PSC/400 web-enables legacy systems with a single command; WebSmart is used primarily to build applications from scratch. Different marketplace entirely. In fact, I'm sure that PSC/400 converted applications could interact with the JSP/servlet version of your tool. You ought to be looking for synergy rather than wasting time trying to bash technology, especially a technology you sell. This is where I get confused. You're here screaming about how CGI is superior to JSP, and yet you sell JSP to your customers. I don't get it. I respectfully ask: have you ever considered that this puts you in a tenuous position regarding your objectivity as a writer? Nah, I'm not too worried about my objectivity. Objectivity does not mean having no opinion, it just means keeping an open mind and forming opinions based on facts. Let's compare objectivity, shall we? I state clearly that I prefer JSP Model II over RPG-CGI, and then proceed to back up my opinion with facts. You, on the other hand, post allegations about the failings of Java which you cannot back up, and when challenged, you avoid responding. Not quite sure where that leaves things, but between you and me, I don't think I'm gonna worry about being tenuous. At the very least, it seems to me you should give serious consideration to revising your mini-bio that appears at the end of your articles, since this is in effect a free advertisement for your products (IMHO). Oh. My. Gosh. You're serious!?! Oh man. Please, go ahead and tell Bob Cozzi about his tenuous objectivity and his free advertising (LAUGHING!). Please! Tell me what he says! I'm dying to hear it! Oh thank you for a great laugh... Joe

                                Comment

                                Working...
                                X