web to 400 communicaiton methods

[J.Pluta]

web to 400 communicaiton methods

Man, I am getting tired of seeing this crap. Time to debunk it once and for all. I was suggesting HTTP as a faster, cleaner, easier means of messaging from IIS to the AS/400 to process data in real time from the web page in IIS, with no tradeoffs to weigh against other than scorn from the messaging gurus. Complete rubbish. The HTML data stream is NOT a faster, cleaner method of messaging, and the tradeoffs are immense. The tradeoff is in the fact that you have to have an HTTP server instance, a web server and a CGI program suite (such as the Strategi stuff that you "don't sell") all running on your AS/400 instead of a simple API call to a server. And the Strategi crap is actually third-party extra-cost software, while messaging COMES FREE with the AS/400. It is not cleaner, because you have to parse the outbound HTML stream from the AS/400 to the NT box, and that is not a trivial feat. In fact, it can be all but impossible, and it's obvious that you haven't really done it, Ralph, or you'd know that. I have a thing against Rube Goldberg layers of technologies, and if the others haven't had their eyes glaze over reading a laundry list of technologies that are recommended to serve web pages, then maybe I'm the only one who noticed... but I doubt it. Rube Goldberg? What in the WORLD do you call that contraption you're foisting on us? Let's see if I get this straight... end user to browser to to Microsoft IIS to NT CGI program to HTTP to IBM HTTP server to Strategi web server to RPG program (to generated HTML to NT CGI to generated HTML to browser to end user)... how many layers is that, Ralph? Any consultant who came to me with a solution like that would be let go immediately. Not even a question asked. Instead, end user to browser to web server to servlet to RPG to JavaServer Page to browser to end user. Cleaner, quicker, with complete separation of design and business logic. For user interface, somebody designs the screens in HTML, then we make the following modifications: This: changes to: <%= dataBean.getFormattedField("Field") %> That's pretty much the extent of the changes. In fact, I have a hard time understanding how the CGI program in your incredibly convoluted design approach is able to get the data from the AS/400 out to the end user; the initial value of a field is imbedded in the actual HTML script, so would have to be passed to the CGI program PRIOR to it being invoked... and how do you do that? It's easy to get data from the user, but much harder to actually intialize the values in those entry fields; that means when the user initially calls a URL, the URL has to invoke a different page on the AS/400, which in turn has to invoke an RPG program, which spits out data as fields on the screen, with the syntax I mentioned above ( maxlength=256>). Then, the CGI program on the NT has to read that screen, find the "INPUT" label in the HTML stream, and parse out the data (welcome to the world of HTML, Ralph). This is why XML was devised as a means of computer-to-computer communication. You see, it's much too hard for a computer to parse out the information content in a web page. The parsing I just told you is a perfect example. There is no clean way to identify each of the "fields" in an HTML stream. This method of "wrappering" one website over another is very difficult and highly dependent upon the coding used. Even more difficult, if the data is only meant to be displayed to the end user, you can't even tell where one field starts and another ends, because the data is just embedded in the HTML stream: Customer Name: My Customer How do you tell the NT program how to find the customer name? Do you scan on "Customer Name:" and then skip one space, then read until a ? What if the HTML designer (who should be completely independent of the process, right, Ralph?) changes it to "Name of Customer:", or even more subtle, changes the to a ? Or adds another space? Or changes the ":" to a "-"? So, Ralph, if you're continuing to insist that you can write an HTML application that runs on the AS/400 (using the Strategi system that you "do not sell"), and then another application that runs on the NT machine, and then "map" the two of them together, I say it might work for a simple prototype but will immediately die when you try to scale it up to anything industrial strength. It's a bad solution and a bad architecture. There. I've stopped mincing words. 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

[J.Pluta]

web to 400 communicaiton methods

One point that was not clear to me was whether the AS/400 in Ralph's scenario should respond by returning HTML, or should it return records? I know Stragegi provides an easy, although somewhat restricted means of returning strait HTML. I think either HTML or records are both viable solutions. If the NT guys want to take records and transform them into HTML, that's no big deal. That's the big point in this whole discussion, Nathan. The AS/400 returns HTML, which is then somehow magically massaged by the IIS into their web pages. That's absolutely ludicrous, for the reasons I stated in my previous message. Parsing HTML and reformatting it into different HTML is not a trivial task, and is highly error-prone. Let me reiterate: HTML is in no way, shape or form meant to be used as a bidirectional means of communication between computers. It is solely designed as a way of presenting information in a platform-independent manner from one machine to a browser, and thence to a human being. Human beings are able to parse information from a presented HTML stream much more effectively than a computer. Any use of the HTML data stream as input to a computer process is wrong, and fraught with design problems. If you choose to communicate between computers, please used a tagged language such as XML, or a flat message, or a standard interface such as SQL. 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

[Guest.Visitor]

web to 400 communicaiton methods

Joe, I was confused at first by some of Ralph's terminology, which led me to some of the same concerns you express here. But, a light began to glow, and now I'm more satisfied. Let me take a shot at clarifying a couple things. Everyone seems to agree that NT/ISS/CGI is an extra layer and not the ideal design. But, according to Susan, its a given parameter she must conform to. The NT layer is not necessarily as smart (complex) as you give it credit. You could design that layer as a simple read and forward link. Read the HTTP request from IIS and forward it to the HTTP server on the AS/400. Then wait for a response from the AS/400 and pass it on to IIS. A Java Servlet could be waiting on the AS/400 to process the request and return a response if they didn't want to use the Strategi middleware. If the response from the AS/400 is a stream of HTML, then why not simply forward it to IIS as a completed page? If the NT guys want to generate their own HTML, then why not simply return a record, or record set from the AS/400? No parsing, no scanning, no transformation of the data stream is needed. Just a strait messaging protocol. You could use the HTTP server on the AS/400 as a plug-in messaging server. A couple things appeal to me about this design compared to a strait messaging interface you could provide through data queues, for example. Both IIS and AS/400 HTTP server support threading. They would be handling the load balancing and scalability issues. The underlying protocol is HTTP, which both servers understand. An incoming HTTP request may be slightly longer than a record in your own protocol, but its trivial. The outgoing response is completely open. It could be HTML. It could be a data structure. Whatever!

[Guest.Visitor]

web to 400 communicaiton methods

Joe, I responded to your comments to Ralph above before seeing this. I agree that sending HTML to IIS, only to be massaged, is ludicrous. Ralph's terminology was somewhat confusing. Thankfully, I don't see HTML massaging as necessary. I attended the Stragegi lab at COMMON last year, so I was able to get past some of Ralphs terminology and see the value. I think Stragegi has many fine features, but now that OS/400 has a built HTTP server, some people won't pay for a third party one. Their pricing confused me. I was told $4000 for a developer's seat plus a cost per session. I don't understand how they track web sessions - they said their server was stateless. I have been happy with the performace of the OS/400 HTTP server, but Ralph may have a point about Strategi being faster. Also, my understanding is that Stragegi uses a request brokering mechanism that routes requests to RPG servers that are in a wait state. The servers are not loaded each time a new request comes in, unlike CGI.

[J.Pluta]

web to 400 communicaiton methods

The NT layer is not necessarily as smart (complex) as you give it credit. You could design that layer as a simple read and forward link. Read the HTTP request from IIS and forward it to the HTTP server on the AS/400. Then wait for a response from the AS/400 and pass it on to IIS. A Java Servlet could be waiting on the AS/400 to process the request and return a response if they didn't want to use the Strategi middleware. If the response from the AS/400 is a stream of HTML, then why not simply forward it to IIS as a completed page? If the NT guys want to generate their own HTML, then why not simply return a record, or record set from the AS/400? No parsing, no scanning, no transformation of the data stream is needed. Just a strait messaging protocol. Nathan, any of your arguments are of course valid. You're a software designer, and you've thought this through. Indeed, I've suggested some of these options. A Java backend, or a message protocol. However, that is NOT what Ralph is suggesting. Ralph's architecture is specifically this: user makes HTTP request to NT CGI NT CGI makes HTTP request to AS/400 AS/400 web server calls Strategi Strategi calls RPG RPG formats message for Strategi Strategi formats HTML output NT reads HTML from AS/400 MT parses message information from AS/400 HTML NT formats "new" HTML output user sees NT HTML output Ralph wants to sell you this idea. Period. (Even though Ralph "doesn't sell Strategi".) This is reflected in Ralph's argument that "professional web designers" design the NT site, while somebody else ("unprofessional" HTML designers?) design the AS/400 web pages. Strategi doesn't output records, it outputs HTML, that's all. Now you've got TWO layers of HTML, one generated by Strategi, one generated by an NT CGI program. And a whole bunch of parsing on the NT side. As a side note, since when are CGI programs written by professional web designers, anyway? Most professionals web designers use tools like Dream Weaver, which is not particularly amenable to CGI. I should know, the sites my company designs for our clients merge both shockwave and actual application panels, and it's not always easy to do it seamlessly. Anyway, regardless of the design issue, the dually staged HTML approach, the more you look at it, is wrong at every level, from fundamental architecture to cost-effectiveness to maintainability to plain old common sense. 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

[J.Pluta]

web to 400 communicaiton methods

And I saw your repsonse after I responded to you earlier response . Strategi's idea of a scripted run through servers is a good one (and indeed, a fairly old one - the idea of running a transaction through a scripted set of processing programs is the core behind most configurable processing architectures). Having servers wait on data queues is a good use of resources (as long as you have a flag separating "often used" from "rarely used" servers; rarely used servers shouldn't sit in the memory pool). If Strategi returned the message via an API, I'd definitely find it interesting. However, the two-level run through HTML that Ralph suggests is a real perversion of what is essentially a very nice architecture. Personally, I want to look into how such a server scripting could be implemented in the servlet/JSP architecture. I think the same idea in conjunction with the true separation of business logic and user interface that JavaServer Pages gives you would be a devastatingly flexible yet powerful architecture. 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

[Guest.Visitor]

web to 400 communicaiton methods

BusinessLink Strategi does not use CGI. They recognized that the threading process to run CGI under Unix did not translate well to the AS/400 and its job concept, and that CGI job startup on the AS/400 was excessive overhead. Hmm well unless Im reading the manual incorrectly There are advantages to running CGI programs in either a user-named or *CALLER activation group. The performance overhead associated with activating a CGI every time that is requested can be drastically reduced. It is important to understand that because the system does not delete user-named activation groups, normal high level language end verbs cannot provide complete end processing. For example, the system will not close open files, and the system will not return the static and heap storage that are allocated by a program. But to me this tells me the AS/400 does indeed support persistant CGI programs and hence the concerns about job startup etc is really a false concern. So the AS/400 HTTP server will support persistant CGIs unlike your IIS CGI solution. David

[Guest.Visitor]

web to 400 communicaiton methods

David, You must close your post with an ending bracket "". Dave

[Guest.Visitor]

web to 400 communicaiton methods

David, If this is consistent with the other stateless servers, the activation groups are kept, open files and all. However, qtemp is cleared and the default activation group is reclaimed. The last point is important if you are using embedded SQL with triggers. In this case a *CALLER trigger runs in the default activation group unless you transfer to a named group. David Morris

[Guest.Visitor]

web to 400 communicaiton methods

Hi Nathan, It has been a great thread, and you just added a bunch of good stuff to it. I'll try to clarify some of the info. Concerning the AS/400 being a superior web server, it only runs IBM's cross platform web servers Websphere and Domino in addition to AS/400 native web servers. The vast majority of both large and small web sites are run on Apache under Unix or IIS under NT. The AS/400 doesn't run Apache or IIS, effectively nullifying it's web serving prowess to the majority of technical decisionmakers who make a career working with these products. Even when Java servlets or Enterprise JavaBeans are chosen as the driving app environment, Sun's Solaris Unix system is usually chosen over the AS/400, and when Notes Domino is chosen, NT is often chosen over the AS/400 to run it. IBM is betting, and dragging us into their bet, that Websphere EJB and Notes Domino will capture new business away from Apache and IIS. Perhaps a robust San Francisco EJB environment will sway Websphere into that position, and along with native AS/400 web server successes, the budding AS/400 web community can win market share. But companies don't choose a computer first and then find software that will run on it, and people who know the software, which is the basis for the arguments that the AS/400 should be chosen to run web sites. Companies choose people, both internal and consultants, who know software and operating systems and who choose computers to run that software. Most web people are Unix Apache or NT IIS, and they won't choose a web server running on the AS/400 to do their work. When the AS/400 community amasses enough industry experience, they may begin rivalling the Unix and NT people for new business, but that won't happen unless and until we have a compelling story to tell with San Francisco EJB or a killer Notes environment that, though cross platform, is a competitive cost effective advantage under OS/400. It should be noted that Apache could have been ported by IBM to run on the AS/400, and we could have contended for the large amount of business that runs under Apache by at least having a chance to bring Unix Apache people in on it in the nascent Unix environment of 4.5 that now includes real Unix shells, but IBM chose instead to not make it available and instead use it as the HTTP core of Websphere. This is exactly the sort of thing that drives companies to open source Unix, be it BSD, Linux, or the recent opening up of Solaris by Sun, to run the open source Apache. IBM has hinted at opening up the base code of Websphere, just as they earlier hinted at porting Apache to the AS/400, but that doesn't interest Apache people. Websphere people? There aren't enough to influence companies to run their web sites on an AS/400. It's a catch 22, like getting experience to get jobs that all require experience. As for CGI under IIS, I tried to describe the IIS programming as CGI or the equivalent. I don't know what the code was because we did the whole thing in a day and I spent more time on the AS/400, but as the company programmers and myself presented a working solution to the CIO, we went over the software driving the solution. The IIS code had Get and Post HTTP calls that ran at the CGI level, or in other words, in code that was invoked by the web pages served from IIS. It would surprise me if any technology running at that level could not request a web page from another server. I apparently didn't describe the process of messaging through web pages well enough. Some thought the IIS pages were being redirected to the AS/400 web server, but the process is not a redirect, and I apparently referred to the process out of sequence, or should have referred to it as returning the web page so as to have been clearer. A web page served by IIS over the Internet is submitted and processed. The IIS program processing the web page requests an AS/400 web page just as a person would through a browser. Because it is machine to machine, the requested web page served from the AS/400 was designed by us as raw HTML with no graphics, Javascript, Cascading Style Sheets, Java applets, ActiveX, or other technologies that enhance the user experience. The IIS program populates the web page as a person would in filling out a form, and returns it to the AS/400. This is a stateless process. There is no persistent connection, session, or job still running on the AS/400 that has memory of the page being sent out and awaiting the return. This is web client to web server, where the IIS web server process has become a web client. The AS/400 web server receives the web page, now filled out with information, and processes it at the CGI level just as IIS processed the original web page, and is still running the program that processes it at this time. The form fields could be anything from one field on the original page to every field. It is likely a subset of the original page, or whatever information is required to be presented to the AS/400 to process and obtain a response. These would be the same fields that would be used as arguments in an SQL statement or parms to a stored procedure call. This data is processed as any web page would be processed by a web server on the AS/400, with technologies ranging from Net.Data generated CGI to Java servlets to Strategi scripting that calls AS/400 programs with designated web page form fields. A web page, now containing computed results, is sent back to the IIS process. This results filled HTML page could have been the one the AS/400 used for the request, with form fields for both the parms and the results, but we implemented a solution that returned a different web page with the results. This was to keep the IIS programmer from having to parse through form field data to get to the form fields with results. We returned yet another web page with error codes. These different web page layouts for returning results were at the request of the NT programmers, and were easily accomplished with the Strategi scripting. For example, an error code returned from the called AS/400 program cased to an error web page, which was populated and returned. The IIS program then parsed through these form fields and, in this case, merged the data in with other data read directly from a SQL Server database, populated the originally requested IIS web page, and returned it to the person running a browser. This happened in real time, with an immediate response time on an internal network, at least with the AS/400 Strategi web server which has no CGI overhead, no AS/400 program startup time, and no access paths to establish, as the business logic to process web pages is placed in dataq driven programs, any programs called from there are left with LR still off, and all file access paths are already established. The scripting allows for business opcodes from different server programs written in different languages, including RPG III, to be called in sequence to process a web page. Strategi does not have any restrictions on what is returned. It retrieves designated web pages and merges designated data into it, along with images, etc. I know of no limitations or inability to meet HHTP 1.1 specs for serving web pages. It does not have ASP or Java servlet extensions, but instead provides for invocations of RPG, Java, ILE, or other language programs based on the web page being processed. It does not, nor do the server program, generate HTML on the fly, but instead serve web pages created with the full gamut of HTML, Javascript, CSS, and Java applet technologies created by anyone without any knowledge of the AS/400 or Strategi. There is a requirement to specify during the creation of the HTML id tags that identify form fields that Strategi looks for to retrieve and populate data. Having done that, any amount of sequencing of business opcode calls, error conditions, and calling of other web pages to process is accomplished in an external script, but the scripting is deliberately void of Visual Basic or Javascript level code of IF statements and DO loops that would constitute snippets of business logic external to the AS/400 programs. The data return process in my solution is back through HTML, and this is what we did. Anything else needlessly brings in other technologies. The data is for populating the original IIS web page, not to download a file, and the HTTP serves as a fast and simple messaging technology innate to the IIS serving process. Strategi scripting provides for array processing, or defining sections of the parm buffer as repeating types, and 20 item records would be populated in the buffer as 20 item numbers, 20 item descriptions, 20 item quantities, etc. Strategi parses the arrays to populate the resulting web page, making the AS/400 business code entirely independent of web page layout. Other web servers and server programs would possibly have other unique strengths or desired capabilities, but the concept of returning results back through HTTP is valid for all and a desirable simplification that doesn't have the tradeoffs typically associated with simplification. Thanks for the compliment on the concept, Nathan. The discussion continues. Regards, Ralph ralph@ee.net

[Guest.Visitor]

web to 400 communicaiton methods

Joe Pluta wrote: "There. I've stopped mincing words." Hi Joe, 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. You can convince them that they made a mistake? Be my guest. Then my solution won't be needed. You also forget that I spent a few months earlier this year writing the back end of a new AS/400 jobs site that I am told will go into production someday, I have no idea when. Two of us did that web site from scratch, web pages with Javascript and CSS, served by ILE, Java, and RPG III server programs, with every job hunting feature specified by the client, in four calendar months. Given that I did all the RPG from design to user acceptance, 12,000 lines of code spread out over 4 server programs comprised of several bound modules, it was way more than your typical four man month effort, but I was only called in at the last minute. I worked night and day through both the Memorial and July 4th weekends, but we delivered on schedule. Strategi on the AS/400 was the server, the web pages were in IFS, and the jobs web site is completely configurable and table driven. Criteria and conditions are read from the configuration file for every page being processed. It's a stateless environment I say all this to point out that the bulk of my work with Strategi was as an AS/400 server. I was asked to go to Chicago for one day to see how a customer who had chosen NT could use the Advanced BusinessLink suite of programs to supply data to NT. The AS/400 people had done their best to get their company to use the AS/400 as the web server, but had lost to the NT faction. I realize you guys think that everybody else just doesn't get it, but some of us have to deal with reality. 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. 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. I said at the time I described it that it probably wouldn't be used even though any web server could be used, including Websphere and Java servlets. The Rube Goldberg laundry list of solutions can come right out of Don Denecourt's articles on JSP, but I'm not going to reiterate them here. Everyone has seen them, and it's not a pretty list. Again, the preferred solution is AS/400 web server to browser, and I just spent several months doing that. The reality is that most companies will not choose the AS/400 as web server, and the NT guys don't even want to deal with it, but they were quite happy with this exchange of data through web pages and considered it trivial to implement. 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. Ralph ralph@ee.net

[Guest.Visitor]

web to 400 communicaiton methods

Nathan Andelin wrote: "I responded to your comments to Ralph above before seeing this. I agree that sending HTML to IIS, only to be massaged, is ludicrous. Ralph's terminology was somewhat confusing. Thankfully, I don't see HTML massaging as necessary." oops, and I thanked you earlier for complimenting the idea. your preferred approach to supplying NT IIS with data from the AS/400 in real time, Nathan? I agree that just being faster is not worth buying another web server, but the Strategi Java emulator that comes with it is potent, small (100k), 1.0.2 so runs in every browser, and supports double clicking on subfile rows to excecute highlighted option text displayed above the subfile along with Page Up, Page Down, and Enter buttons. An app with F4 promptable windows would allow a user to navigate through it with a mouse, only typing when you would in Windows. Also, the scripting that bypasses CGI and servlets is unique and essentially has you doing dataq programming against top of the line web pages, rather than program generated HTML. But those are niceties, and I'd like to hear what your preferred solution to communicate with NT IIS is. Ralph ralph@ee.net P.S. They have some built in stuff such as Java AS/400 emulators that you log in to Strategi to use. Those are the seats in addition to the $4,000 web server. The work I did for the jobs site was for either anomynous or logged in users (security enforced by the browser). Search agents could be created and results e-mailed if you logged in. Of course, anomynous users were unknown and there is no seats involved there.

[Guest.Visitor]

web to 400 communicaiton methods

Joe Pluta wrote: "Ralph wants to sell you this idea. Period. (Even though Ralph "doesn't sell Strategi".) This is reflected in Ralph's argument that "professional web designers" design the NT site, while somebody else ("unprofessional" HTML designers?) design the AS/400 web pages." Everything you describe about my approach is accurate, Joe, so I wouldn't have commented but for the impression I've apparently left as you note above. My argument about professional web pages wasn't limited to the NT, and I stated the other day that inserting Java servelet calls is no big deal, I wouldn't recommend Strategi just to avoid that, but I was comparing professional web pages to the skeleton HTML that one would lick out of a program versus using Dreamweaver. 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? As for the raw HTML used to transport data, we just typed it into Notepad since it was so sparse and stored it in IFS. With the job site, pages were done inhouse with Javascript and CSS2 by the other programmer working with me, but we had a graphics specialist inhouse who helped. Again, I bounce around from subject to subject so much that I know it's confusing, but that particular rant has to do with web pages not being suitable for business processing, but instead are suitable for the public when created professionally, not some stupid Cold Fusion output or some roll your own HTML. But I could misunderstand what can be done. I don't close my eyes to better solutions. I also accept them when I see they're better than what I have done in the past. XML tags can change just as much as HTML tags can change. Parsing through text is parsing through text. There's both support within IIS for dealing with form variables and XML. I have nothing against XML through sockets. I recommended that my visual interface for the AS/400 be based on XML, for example. I just pointed out a seamless HTTP process innate to web server processing that I had used that worked like a charm with no drawbacks, other than you'd rather parse through XML than HTTP and you consider an HTTP server unacceptable but something, not pointed out by you, as an ok middleware from NT. Except you never even addressed the stated problem and how you would solve it. Ralph ralph@ee.net

[Guest.Visitor]

web to 400 communicaiton methods

David Bye wrote: "But to me this tells me the AS/400 does indeed support persistant CGI programs and hence the concerns about job startup etc is really a false concern. So the AS/400 HTTP server will support persistant CGIs unlike your IIS CGI solution." I agree with your assessment, David. The slowness of the IBM web server had been partially attributed to CGI. A persistent CGI eliminates any advantage of Strategi not starting a job for each web page. I have repeated that the solution works with any web server, but had mentioned the speed of Strategi against others as one of the advantages for using it. I much prefer recommending a bundled product rather than a third party solution.....the feedback I've heard was that Websphere required enormous amounts of memory and was slow. If it does the job, by all means I would recommend using it, servlets or CGI either, whatever suited the developers and did the job. The Strategi web server was highly tuned to the AS/400 for speed, and I would hope that Websphere users made the CGI jobs persistent.....I have seen references to FastCGI elsewhere.....but I will drop references to any advantage over CGI....if it's faster, fine.....but it's all relative....if the pages are whipping out than I'd use the bundled serve r, even if there was some CGI code or equivalent to write. I just found the seamless web page to RPG scripting of Strategi to work as straight forward as dataq programming. If Joe does the same thing with JSP and provides a bundled JSP that does the same thing, the same benefits are there. I'm just talking about clean, fast executing solutions, and persistent CGI would certainly be in there, and so would Joe's implementation of scripting from within a JSP. Oh, and the NT IIS CGI or equivalent is already a base that we have to deal with when the customer has already chosen NT to serve the web pages, whatever the overhead is. It's from there that my solution starts, not part of my solution as if I recommended it. Thanks for the info, David. Ralph ralph@ee.net

[Guest.Visitor]

web to 400 communicaiton methods

David bye wrote: "Just because you couldnt get MQ to work effectively that does not mean it doesnt ! I really hate this type of comment "I cant get it to work" therefore it does not work. There are a number of sites using MQ on the AS/400 in realtime in an effective manner. My experiences have not been the same. Ive seen some bad implementations but by correcting the design and code the performance issues went away." My experience was that we pushed several hundred thousand transactions a day between 10 large AS/400's handling regional distribution centers. This was not real time, just assured delivery and processing of customer master data. We had a full time MQ admin, all of the Customer Master programming staff dealt extensively with the queue triggers, and IBM was brought in to work with us as needed. This particular setup was one queue per record format, with each queue being defined with a different length, and several queues between each AS/400. The administration was a little complex, but the scheme worked fairly well. I was AS/400 software R&D for this company, and we decided to use MQ for the Item Master group as well to distribute changes. I was involved because I was looking to bring item transactions back to the Item Master AS/400 in real time, and hit the Item Master AS/400 with MQ transactions from the other AS/400 green screen apps to replace the 4 times a day FTPs to all machines that was taking place. I wanted to piggyback on their distribution work and use the MQ channels being set up for change distribution for this. We found that MQ had a 16 meg buffer limit, which we exceeded when an AS/400 was down for backups. We worked around it by caching the records in a file and then feeding them into MQ until the Full trigger fired, but our AS/400 programmers considered the whole thing bizarre when we could just make the file a DDM file. We sequenced the records and sent back an ack or err record from each AS/400, and really, what else did we need that MQ would have done? A DDM file for each destination AS/400 as supported by OS/400 reliably handled whether the destination AS/400 was up or not, and held output until the connection was made. No extra file caching, no triggers, no API's, even though we had the API's written and ready to use, but still, it was clean. We put an EOFDLY on the receiving file and it processed like a charm, with us writing ack records back as we processed them. The speed was incredible. I continued to try to use MQ for my real time retrieval of master data from a central AS/400 because we had multi platform requirements that didn't allow the DDM solution, but MQ would hang for about 10 seconds every couple of hundred records. I had run across a worse hang many years ago with PC/DDM (I know it's not MQ, and if anything it should reflect on DDM, but still, it was my experience) and found that unless I put a 1/3 second delay between record I/Os that the AS/400 communication job would hang, really just break. I know it's not the same, but it was similar that full burst mode worked for a couple of hundred records, then hung. It was unacceptable for every nth green screen user to wait 10 seconds while we waited for MQ to return an answer on item info to merge in with local data and send the green screen down. IBM could not solve the delay problem or improve the process, as I implemnted a very standard approach right out of the manual. This was '98, and perhaps MQ has overcome the 16 meg buffer problem and periodic delays of 10 seconds to resume processing, so perhaps I shouldn't comment that it's too slow for real time retrieval of data from the AS/400 to NT to populate a web page unless I tried it this year. The customer in Chicago this summer where I did my HTTP messaging solution had some business partners with AS/400's and asked if Strategi could exchange data between the AS/400s. BusinessLink did have some new Java to Java stuff between AS/400's going, but I recommended that the customer look at exchanging transactions with MQSeries. It was not real time with a customer waiting for a web page but online assured delivery type requirements. They used MSMQ. Those NT guys.....you just can't trust them. Ralph ralph@ee.net