Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

web to 400 communicaiton methods

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

  • #61
    web to 400 communicaiton methods

    You conveniently forget that this solution is for a company which has chosen NT as their web server. You come in and tell them that the AS/400 will be the server because you say so, and you're the one out the door, not me. I'm not a consultant, I have a job which has nothing to do with Strategi, and I'm basing my comments on my experience with Strategi over the last three years to address a specific request for a solution with NT. Except you never even addressed the stated problem and how you would solve it. I have no problem with you addressing your one problem, that of tying an entrenched NT system with an AS/400, even though I would still opt for servlets and JSP rather than CGI. There is no viable reason not to use servlets, a competent programmer can learn how to program them in a week. In fact, I give presentations at COMMON that teach the basics in an hour and a half. As for the repeated "you don't sell" comments, you're the only one selling something in here, even though you give base stuff away to create a market. This is where you're way offbase Ralph. The only thing I "sell" is consulting for my revitalization architecture, which has no bearing on this discussion, since it does something your Strategi solution CANNOT do: put EXISTING AS/400 programs on the web quickly and cleanly. The servlet/JSP architecture which I recommend for accessing data as opposed to the Strategi kludge is completely non-proprietary and completely free (unlike Strategi) and has nothing to do with my PBD packages. It's from Sun and IBM, Ralph, not from Pluta Brothers Design. As I said, we implemented it in one day, and they had no problem parsing through the HTML to retrieve data or stuff data. But again, since XML is a holy grail, parsing through XML text is ok, but not through HTML text. The messaging gods have spoken. XML tags can change just as much as HTML tags can change. Parsing through text is parsing through text. If you truly believe that, then you might want to read a primer on XML. HTML has FORMATTING tags, which do nothing to actually identify the data within the stream. XML, on the other hand, has data definition tags which identify each individual field within the data stream. They do NOT change. There are no formatting instructions in XML; that belongs to an XSL (an XML Style Sheet). An XSL can translate the same XML document to HTML, WML, PDF or whatever else may come down the pipe, but you have no fear of losing the original data. There are a number of other benefits to be derived from XML, but if you don't understand the basics, the others are pretty arcane. Perhaps I read wrong about generating HTML from programs, and perhaps every example of a web page I've seen coming from the AS/400 is pathetic for some other reason? The ability to put a quality web page out in conjunction with business data is something that has to be learned over time; few people do it well, as it is a synthesis of two widely divergent skill sets. However, it can be done, but it doesn't need something as convoluted as your approach. Instead, a simple design and the use of CSS or frames and you can have highly professional pages without any hassle. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

    Comment


    • #62
      web to 400 communicaiton methods

      Joe Pluta: wrote: "If you truly believe that, then you might want to read a primer on XML. HTML has FORMATTING tags, which do nothing to actually identify the data within the stream. XML, on the other hand, has data definition tags which identify each individual field within the data stream. They do NOT change. There are no formatting instructions in XML; that belongs to an XSL (an XML Style Sheet). An XSL can translate the same XML document to HTML, WML, PDF or whatever else may come down the pipe, but you have no fear of losing the original data. There are a number of other benefits to be derived from XML, but if you don't understand the basics, the others are pretty arcane." Yeah, XML is such an advancement of the state of the art - the equivalent of DIF files with the field names repeated in front of every field. I can barely repress my awe. Granted, it is a nice advancement in that we have enough bandwidth now to tag every field and have heirarchies so that we're not limited to flat record layouts anymore as in a DIF file, but I'm so glad you explained all that complicated stuff to me. I have the source to Apache Cocoon and Xalan and kvisco.xsl in Exoffice but I just couldn't understand all that stuff. Thanks. And so, with HTML, since it only has FORMATTING tags, we would have no idea what anything is. We're so lost without XML. Those NT guys were clueless to listen to me and parse through HTML to get data. I really don't deserve to be in IT, I guess. Maybe I'll find something I can handle, like flipping burgers. Thanks so much again. Ralph ralph@ee.net

      Comment


      • #63
        web to 400 communicaiton methods

        Ralph, I thought it had been announced that a native AS/400 Apache port was due out soon as a PTF for V4R5 and would be the default web server from then on? Supposedly, it is based on the Apache 2.0 code which is only in Alpha/Beta on other platforms and includes some improved threading support developed by IBM. Also, it will be available as binaries only, the AS/400-specific source has not been made part of the Open Source Apache. You should subscribe to the Ignite400.org mailing list if you are interested in this issue. Mark Phippard

        Comment


        • #64
          web to 400 communicaiton methods

          Yeah, XML is such an advancement of the state of the art - the equivalent of DIF files with the field names repeated in front of every field. I can barely repress my awe. Granted, it is a nice advancement in that we have enough bandwidth now to tag every field and have heirarchies so that we're not limited to flat record layouts anymore as in a DIF file, but I'm so glad you explained all that complicated stuff to me. I have the source to Apache Cocoon and Xalan and kvisco.xsl in Exoffice but I just couldn't understand all that stuff. Thanks. And so, with HTML, since it only has FORMATTING tags, we would have no idea what anything is. We're so lost without XML. Those NT guys were clueless to listen to me and parse through HTML to get data. I really don't deserve to be in IT, I guess. Maybe I'll find something I can handle, like flipping burgers. Your professional opinion is that XML is no more than DIF files? Okay. Well, Ralph, now that the conversation has gotten down to condescension and ridicule of things not understood, I guess it's time to end it. For the record, my final opinions: 1. Your HTML pass-through was an inventive solution to a bad set of parameters: mainly the requirement to use NT CGI programs but NOT support sockets or any other messaging technique. Personally, I would not take this business. There are plenty of other people out there who will implement a bad architectural decision, as long as the client pays. My company is not one of them. 2. HTML is a bad technique for computer-to-computer data transmission. (Of all my opinions, this one is the one everyone I know agrees with, except you.) 3. Servlets and JSP are superior to CGI, especially in the area of separation of user interface and business logic. 4. XML is a large-bandwidth but high-integrity data transmission standard and should be explored whenever variable text (as opposed to flat-format) data communication is considered. Nothing earth-shattering here, and nothing to do with my packages or my company. My company, eDeployment, focuses on using my revitalization APIs to put existing AS/400 systems on the Web, which is completely outside the realm of this discussion (although we also integrate really nice graphical web content with AS/400 web applications). I'm going to sign off this conversation for now. Feel free to rebut whatever you'd like at your leisure. Joe src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

          Comment


          • #65
            web to 400 communicaiton methods

            Ralph, My parroting the word "ludicrous" was a mistake. I regreted using that word soon after I posted the message. Sorry. It would have been more diplomatic to say that I don't agree with the idea of generating HTML on the AS/400 then writing code on the NT to massage it (scan, parse, insert, ect.) prior to delivering it to the end-user. I'm intrigued by the idea of IIS receiving an HTTP request (GET, POST, PUT, ect.) from a user and forwarding it to an HTTP server on the AS/400. Prior to hearing your suggestion, I was considering writing my own TCP/IP handlers on both AS/400 and NT. But, why not just use the two TCP/IP servers that are already there (IIS and AS/400 HTTP Server). Why not write a generic ISAPI interface under Windows that would forward the request to the AS/400 HTTP Server, wait for a response from the AS/400, then simply pass it back to IIS and to the end-user. I would put the dynamic generation of formatted text (HTML, XML, WML, ect.) on the AS/400. IIS and my generic ISAPI routine running under IIS would be little more than a gateway.

            Comment


            • #66
              web to 400 communicaiton methods

              Ralph, Here is a link to the iSeries web site detailing the availability of the Apache web server on the iSeries. It looks as though it is scheduled for 12/15/2000 as a PTF. http://www.iseries.ibm.com/products/...ces/Apache.htm Mark Phippard

              Comment


              • #67
                web to 400 communicaiton methods

                Ralph, Your post contained a lot of information and I can't comment on all of it. But, maybe I should say something of my bias toward using the AS/400 as an application server as opposed to NT. I've written a lot of software under Windows in a client-server environment and discovered that there is much to say for the stability, integrated environment, and vertical scalability of the AS/400. I think the AS/400 beats NT as an application server. Its a more productive development environment, and virtually eliminates a broad range of technical challenges faced by NT application engineers. NT is great for serving static pages, but when people get to the point where they want to integrate a database and post transactions they should consider moving that to the AS/400. The NT Web Master will holler that he thinks the solution is an MS SQL database because in-the-box applications from Microsoft are so easy to set up and offer so many cool features. The hidden problem is that they fall apart under heavy loads. After that, the next thing to try, is moving MS SQL Server to another box - separating it from the box the application runs on in order to get more steam out of the application box - only to find out the network is another bottleneck. Then more features and applications are requested. Since the 1st application box is overburdened, the decision is made to get another box and balance the load with load balancing software at the network level. After a while, the stability, manageability, and deployment problems become overwhelming and the AS/400 starts looking better. The reason I bring this up is because a lot has been said about NT winning the political battle. But, it seems to me that if the data the application needed was AS/400 based, it would have been an opportunity for the AS/400 guys to have more pull over the design of the system - an opportunity to base the application on AS/400 technology. In other words, limit the scope of work done on NT to serving static pages and providing a simple gateway to the AS/400 to do the job of application serving.

                Comment


                • #68
                  web to 400 communicaiton methods

                  Thanks for your post, Richard. Give me the rest of the week to look at the live demo. I just got back in town - literally.

                  Comment


                  • #69
                    web to 400 communicaiton methods

                    Mark Phippard wrote: "I thought it had been announced that a native AS/400 Apache port was due out soon as a PTF for V4R5 and would be the default web server from then on? Supposedly, it is based on the Apache 2.0 code which is only in Alpha/Beta on other platforms and includes some improved threading support developed by IBM. Also, it will be available as binaries only, the AS/400-specific source has not been made part of the Open Source Apache. You should subscribe to the Ignite400.org mailing list if you are interested in this issue." I was one of the original subscribers to the Ignite.400 site, and opted for being on the mailing list at some point I think for about a year, but it was pretty focused on people trying to get their web sites working, in other words, pretty dry reading...... As IBM has done the work of porting Apache to make it the base of Websphere HTTP, I can see them breaking the binaries out and making Apache alone available. I'd be major league surprised if they made it the default over Websphere Standard, though. I can't even imagine it. And what's this stuff about taking open source, using it, and closing the resulting source. If it's too keep the AS/400 secure, then I'd like to hear that. I know they've given a lot of technology back, especially to try to make Linux enterprise ready, but they seem to use open source and talk open source but not walk the walk of open source. They did finally open the Toolbox, and the people running JTOpen seem pretty cool from their comments. But closed Apache source isn't going to let us compete for Apache talent on the AS/400....IBM should know that. I had just forwarded Bleddyn's post on as400.misc to BusinessLink with the hope that they will get their Fortune 20 catalog site and their customer's jobs site that they will host on Ignite's list. Thanks for the info, Mark. Ralph ralph@ee.net

                    Comment


                    • #70
                      web to 400 communicaiton methods

                      Nathan Andelin wrote: "It would have been more diplomatic to say that I don't agree with the idea of generating HTML on the AS/400 then writing code on the NT to massage it (scan, parse, insert, ect.) prior to delivering it to the end-user. I'm intrigued by the idea of IIS receiving an HTTP request (GET, POST, PUT, ect.) from a user and forwarding it to an HTTP server on the AS/400. Prior to hearing your suggestion, I was considering writing my own TCP/IP handlers on both AS/400 and NT. But, why not just use the two TCP/IP servers that are already there (IIS and AS/400 HTTP Server). Why not write a generic ISAPI interface under Windows that would forward the request to the AS/400 HTTP Server, wait for a response from the AS/400, then simply pass it back to IIS and to the end-user. I would put the dynamic generation of formatted text (HTML, XML, WML, ect.) on the AS/400. IIS and my generic ISAPI routine running under IIS would be little more than a gateway." Hi Nathan, I know the thread has run for several days and some of what I've said has been repeated ad nauseum....so I'll try not to again. The solution I implemented did not use CGI or generate HTML. What the NT guys did I had no control over, and I don't know if they actually wrote a CGI program for IIS or used other IIS technologies, but from there they requested a web page from the AS/400 web server. The one I used, BusinessLink's Strategi, has no CGI. It is told what AS/400 programs to call for each web page in a script named the same as the web page with a different extension. So I wrote no CGI nor used any eRPG API's. However, any AS/400 web server could have provided the page using whatever one wants to do...eRPG, Java servlets, Lansa code, etc. The web pages used for this were created and stored in IFS as any web pages served directly to a browser would be. They were just sparse HTML we typed into notepad with no graphics, etc., as no person would see these pages. They just went back and forth between NT IIS or whatever the site's web server is and the AS/400 web server. No HTML is generated. Your idea is along the lines of what I did, in that most data came from the AS/400 and the NT web server forwarded data to the AS/400 web server. However, the NT people had some local SQL Server data also involved, and they merged the data before responding to the browser with an updated web page. Some comments have sounded like this was a burden for the NT people, when in fact they knew what they wanted to do and it was only a question of how they would retrieve the data from the AS/400. They had considered ODBC, RPC, and MQSeries before bringing me in to see what kind of data communications technologies BusinessLink had. Or to put it another way, BusinessLink was trying to sell them some new Java communication technologies, but I recommended the existing Strategi web server instead. They saw the solution as trivial to implement, but weren't sure about the speed. They were astounded at the speed. The problem with your premise, Nathan, is that if NT people are involved, they are not interested in being a gateway to forward web pages to the AS/400, they just need some data from the AS/400 in a hurry. If AS/400 people are in control, they would serve directly from the AS/400. The number of AS/400 people who are in control and prefer to use the NT as a gateway to the Internet would constitute the market for your idea. I'd prefer to use a small AS/400 and DDM rather than NT. If they are smitten with NT IIS technologies, they wouldn't use it just to forward to the AS/400, in my opinion. Thanks for the remarks, Nathan. Regards, Ralph ralph@ee.net

                      Comment


                      • #71
                        web to 400 communicaiton methods

                        Mark Phippard wrote: "Here is a link to the iSeries web site detailing the availability of the Apache web server on the iSeries. It looks as though it is scheduled for 12/15/2000 as a PTF. http://www.iseries.ibm.com/products/...ces/Apache.htm" Thanks for the link, Mark. This is what I was saying....IBM has made Apache the HTTP base of Websphere. I thought it had already happened the way they were talking. When they say server instances co-existing, I read that as pre- and post- Apache Websphere, not Apache alone, binaries or otherwise. Of course, my interpretation of IBM marketing announcements is open to interpretation. Ralph

                        Comment


                        • #72
                          web to 400 communicaiton methods

                          Nathan Andelin wrote: "The reason I bring this up is because a lot has been said about NT winning the political battle. But, it seems to me that if the data the application needed was AS/400 based, it would have been an opportunity for the AS/400 guys to have more pull over the design of the system - an opportunity to base the application on AS/400 technology." I leave it to others to comment on how much pull the AS/400 people have over web server decisions. I've seen one large AS/400 shop deliver a home run this year with an AS/400 catalog web site....but saw a lot of AS/400 people shut out elsewhere. Ralph ralph@ee.net

                          Comment


                          • #73
                            web to 400 communicaiton methods

                            I started out to reply/rebutt in detail, but figured that wouldnt get anywhere. From reading the description of the implementation its best put "I wouldnt have done it that way myself!" I can see your experience was not desired. Again all I can reiterate is others, including myself, have had more satisfying experiences. For one client MQ is used for:
                            1. VISA Electron (Debit Card) Authorisation Transactions
                            2. CashCard (Smart Card Stored Value) Top Up
                            3. Mobile Banking (WAP) inquiries
                            4. Replication of data changes
                            5. Corporate Banking Inquires
                            6. Treasury Settlement
                            7. PC Client Inquiry Terminals
                            8. A number of internal applications being integrarted.
                            Daily transaction volumes are just over 100,000 to a single AS/400 with more being routed between UNIX, NT and CICS. Its a mix of realtime, including direct customer access, and unidirectional asynchronous messaging. There is one very part time MQ administrator. As for performance perhaps you care to look at an old href="http://www4.software.ibm.com/cgi-bin/bookmgr/bookmgr.exe/BOOKS/MP42/3.1"> IBM AS/400 MQ report Note the impact of increasing the number of queues has on performance, and relate that to your implementation using one queue per record format. Anyway we're straying from the original discussion or point I was trying to make. Which was there are other options for webservers to interface to the AS/400. I am not advocating putting webserver on the AS/400, my clients are banks and there is no way they would feel comfortable with a single box being the webserver and the core banking host. Also in point of the persistant CGI, I may be misreading your response but, you seem to imply this requires websphere and that would be incorrect. Its available with the standard/integrated/FOC AS/400 HTTP server. David "Smart people (like smart lawyers) can come up with very good explanations for mistaken points of view."

                            Comment


                            • #74
                              web to 400 communicaiton methods

                              Hi David, How come everytime I describe what somebody else did, it gets called *my* bad idea? I'm a messenger who's been shot more times than a messenger pigeon. I was AS/400 Software R&D for this company , but a company that was a Fortune 200 at the time, #47 now despite me being there, doesn't hand a major implementation like that to lil ol' me and say wire our national network of distribution centers together with MQSeries, architect it, program it, and staff it. I wasn't even involved, because it wasn't R&D. They had a boatload of expensive IBM consultants, and IBM business partners, and IBM reps all over it with a boatload of local consultants and a boatload of employees. If the end result sounds like it was done by committee, it was. If you got the impression of how byzantine the architecture was, then I described it well. I said it was complex to administer, but that it worked pretty well. I also said it was for assured delivery and made no comments about the speed of those transmissions. You can ad dress all your comments on how bungled it was to IBM's experts, David. It worked, but it needed a huge amount of babysitting. I said that Item data was to be distributed as well through yet another layer of queues, and that I was going to use it, but we ended up using DDM because we had to cache the data anyway. The reason the data backed up over 16 meg is because the Item Master guys didn't have a different queue for each record layout, thus the one pipeline filled up. Customer Master didn't have the problem because there were so many queues. I tried to continue on with my own queue on the development box talking to one other AS/400. As I said, it was a vanilla implementation of MQ, kept simple to establish baseline real time performance, and IBM could not resolve the periodic hangs of several seconds. Of course, there wasn't anything they could do to resolve it. Their standard answer was to dedicate more hardware to MQ, either on the same box or a different box. You must think I'm really stupid to describe a nightmare of an MQ layout and then tell you I base my opinion of realtime performance on it. In R&D, as I'm sure you well know, you set up a small prototype, establish baseline results, and then build from there. A vanilla implementation is just that, sweet and simple. I will say that I'm surprised that a person as knowledgeable about MQ as yourself doesn't know what Hurley had to do to resolve Delta's problems. You think I have a thing against MQ even though I had just recommended it to the Chicago people where I implemented the one and only idea to be judged on, my HTTP messaging idea. I didn't choose NT to be a server, and I didn't architect the MQ layout that makes you think I base statements on my own bad architecture. I didn't even base my statements on somebody else's bad architecture. I based them on one queue going between two large AS/400's, and got IBM to take a look to see if they could improve it. Since it was so simple, there was nothing to improve. Of course, I knew that, but I have to do those things to show others that all possible was done, whether it be the company or others such as yourself. And yes, you misunderstood what I said about persistent CGI, David. Don't know what I said that made it sound like only Websphere could do it, all I said was that it was a good thing and that CGI had been attributed to some of Websphere's slowness but that persistent CGI should take away that as a reason. Also, the standard integrated webserver is Websphere as far as I know, Websphere Standard. Also, the webserver on an AS/400 can serve to other boxes in this scheme with probably less overhead than an MQ server on the box, but I wouldn't hesitate to put both on it. I agree that the often cited recommendation to just fire up a web server on a production box and serve everybody from there is totally unrealistic. Also, I'm glad that MQ does work fast enough. I wanted it to. Pulling data in realtime to feed certain fields of green screens from our multiple platforms would have been a big win. I wanted it to work. I still recommend it over ODBC and RPC for retrieval of data to populate web pages, but think that my HTTP messaging proposal is faster and simpler than MQ with no cons to weigh against the pros. But I recommended it to the same customer for exchanging transactions with business partners, but as I said they used MSMQ instead, which is the stuff that happens when the NT people start driving the technology behind the business processes. Regards, Ralph ralph@ee.net

                              Comment


                              • #75
                                web to 400 communicaiton methods

                                Hallo Susan, I've been reading the discussion with big interest. So what kind of solution did you chose in the end. Kenneth

                                Comment

                                Working...
                                X