web to 400 communicaiton methods [Archive]

Guest.Visitor

10-02-2000, 12:41 AM

Hi Susan, I'll summarize the solution and then drill down to any details you want should the concept interest you. I went to Chicago a few months ago. The situation was the same....info on the AS/400 but the company's website was on NT IIS. The customer also had the Advanced BusinessLink Strategi web server on the AS/400 and there had been a political turf battle over who would do the web serving. Without even serving one page from the AS/400, the NT guys won the political war. I was called in to help the company figure out how to get AS/400 data to the IIS served web pages in real time. ODBC and sockets programming were the only traditional options that anyone knew of, Susan. FTP was out, Java to Java was out (I can hear the howls of protest now - but the M$ guys are into IIS, SQL Server, and CGI via COM drivers- exchanging data with Java on NT which would then communicate with Java on the AS/400 is not of interest to them - anyway it's just a more convoluted way of doing ODBC - they could care less that "J"DBC would run on another platform besides Windows). MQSeries and other transaction messaging systems were considered a complicated, expensive, slow alternative to doing their own sockets programming. But they weren't keen on ODBC and the NT and AS/400 were fighting so they weren't in a mood to collaborate with a sockets protocol. The AS/400 guys also had the Strategi web server installed and wanted to use it. So as I sat there getting briefed on the situation and found out they wanted IIS web pages populated from the AS/400 in real time, I had an idea. The Strategi web server is ready to receive web pages, so what if IIS just forwarded them to Strategi? I asked the NT programmers if they could send a page to the AS/400 from within the IIS CGI. They said it was embarrassingly trivial. I told the AS/400 guys to just act like the pages were coming directly from the customer. It was irrelevant that it passed through IIS first. Actually, as I explained that the AS/400 was still doing web serving but internally and not requiring their production AS/400 to be exposed to the Internet, they saw it as the best of all worlds. All the development on the AS/400 for this project was web development, yet they weren't on the Internet. The IIS guys stayed within web technology to communicate with the AS/400. It was transparent to them. They were happy. They didn't pass images to the AS/400 in web pages sent to the AS/400. We stripped incoming data that served as keys from an IIS web page and sent some web page with that data to the AS/400. Strategi received the web page and invoked RPG servers to process the data, based on configurations for the web pages via Strategi scripting. There was nothing AS/400 specific in the HTML and whatever processing took place was transparent to the IIS guys. One of several web pages on the AS/400 was returned with data or error information to the IIS CGI program, based on what the IIS guys wanted to see. The AS/400 didn't know or care that it was talking to another web server. The IIS web page going out to the customer contained real time data from the AS/400, and they got it as fast as any other web page would be served back to them. They simply populated a web page kicked out of CGI with some data from the incoming IIS web page, and then in turn transferred AS/400 results to an outgoing IIS web page. We did this in one day and put the solution into the test environment. There were some other pieces that they had to do, but they now knew how to glue the systems together. There was no CGI or "e-" programming on the AS/400. The Strategi web server looked up the corresponding script for the web page (x.hsm for x.htm). The script defined what server programs and routines were to be invoked for this web page, and concatenated specified fields from the web page to be placed in a dataq like buffer and then called each server designated in the script. The script also specified what data from the dataq return were to be placed in a web page and sent back. Let me know if you would like any more details on this approach, Susan. Regards, Ralph

Guest.Visitor

10-02-2000, 03:42 AM

Ralph, Are the the IIS gurus are using the WININET API ? If so then you need to be aware of the default will limit this to support only 4 concurrent connections at one time. There is a regedit "fix" with the warning this breaks the HTTP 1.1 rules. Though so far I havent seen any problems with setting it higher. Its just that I had a client request some help with stress testing their internet applications and this was a very limiting factor especially where the CGI was long running. If they are not using the WININET APIs I would be interested in getting some more details of how they implemented the redirect. Thanks David

J.Pluta

10-02-2000, 06:01 AM

We did this in one day and put the solution into the test environment. There were some other pieces that they had to do, but they now knew how to glue the systems together. There was no CGI or "e-" programming on the AS/400. The Strategi web server looked up the corresponding script for the web page (x.hsm for x.htm). The script defined what server programs and routines were to be invoked for this web page, and concatenated specified fields from the web page to be placed in a dataq like buffer and then called each server designated in the script. The script also specified what data from the dataq return were to be placed in a web page and sent back. So what you've done is created two different web applications, one "wrappering" the other. And so, rather than a simple messaging system to communicate between one web application and the servers, you've instead introduced a second HTML layer, using Advanced BusinessLink. Of course, as you've said, since you have the business servers in place, you could just as easily send the data to them via a message or an RPC or a data queue; but because the political climate didn't find that acceptable, you've got to now synchronize the HTML generated from the AS/400 with the HTML on IIS (for example, all the field names in the forms on the NT box must coincide with the field names expected by the AS/400 side, or else you have to do some conversion in between). Change control has to be an interesting endeavor. Definitely a unique solution to a novel requirement: having to have two dissimilar web servers running simultaneously. Joe <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

nycsusan@hotmail.com

10-02-2000, 07:29 AM

Ralph, Thanks so much for the details. Of COURSE I have more questions! :-) " ... there had been a political turf battle over who would do the web serving. Without even serving one page from the AS/400, the NT guys won the political war. ODBC and sockets programming were the only traditional options that anyone knew of, Susan. FTP was out, Java to Java was out (I can hear the howls of protest now - but the M$ guys are into IIS, SQL Server, and CGI via COM drivers- exchanging data with Java on NT which would then communicate with Java on the AS/400 is not of interest to them " This is precisely what I (we) are dealing with. NT is the company standard for a web server, period. The fact that our data is on the AS/400 and the fact that the 400 can be used as a server is irrelavant to the powers that be. We are circumventing the politics by running Domino on our AS/400s and serving up that application on the web. But this latest endeavor of putting customer invoices on the web has already been absorbed by the "E" people, and that means NT. "MQSeries and other transaction messaging systems were considered a complicated, expensive, slow alternative to doing their own sockets programming." We looked at MQSeries too. It's overkill for what we need. "The AS/400 guys also had the Strategi web server installed and wanted to use it. So as I sat there getting briefed on the situation and found out they wanted IIS web pages populated from the AS/400 in real time, I had an idea. The Strategi web server is ready to receive web pages, so what if IIS just forwarded them to Strategi? I asked the NT programmers if they could send a page to the AS/400 from within the IIS CGI. They said it was embarrassingly trivial. I told the AS/400 guys to just act like the pages were coming directly from the customer. It was irrelevant that it passed through IIS first." Is Strategi really needed? Sorry for being so clueless here, but does Strategi run on NT or on the 400? I am guessing it runs on the 400, and if so, can we use NetFinity instead? NetFinity was installed to run with Domino (so that it could communicate better with M$ products like Excel and Word). Can we use NetFinity without interfering with the other (Domino) application? Also, in NT lingo, what do I ask the NT guys for? Will they understand what I want if I tell ask them to "send a page to the AS/400 from within the IIS CGI?" Thanks again, Ralph! Sue.

Guest.Visitor

10-02-2000, 07:56 AM

How about Net.Data?

Guest.Visitor

10-02-2000, 10:21 AM

Not a redirect, David, and no "connections". Doing the HTTP Posts and Gets (I think that's the right terminology) to the AS/400 web server IP address is not a pervasive connection, just the stateless web server access ala the browser. Pure CGI programming in IIS.....don't know what components or API's they used, but they showed me some code which did a Post and Get. Also, scaling is internal to AS/400 with multiple server programs, not multiple boxes, so there's only one IP address for any NT box to talk to. Again, the original web page with graphics is not redirected to the AS/400. Key data is extracted in IIS CGI and posted to the AS/400 web server. It is just like messaging, but with the HTTP protocol. I confess I never preplanned this solution, it just came to me when crunch time came. Regards, Ralph ------------------------------------------------- Ralph, Are the the IIS gurus are using the WININET API ? If so then you need to be aware of the default will limit this to support only 4 concurrent connections at one time. There is a regedit "fix" with the warning this breaks the HTTP 1.1 rules. Though so far I havent seen any problems with setting it higher. Its just that I had a client request some help with stress testing their internet applications and this was a very limiting factor especially where the CGI was long running. If they are not using the WININET APIs I would be interested in getting some more details of how they implemented the redirect. Thanks David

Guest.Visitor

10-02-2000, 10:32 AM

Guest.Visitor

10-02-2000, 10:43 AM

No, Susan, Strategi is not needed. It is a native AS/400 web server that takes full advantage of the AS/400 unlike the cross platform Domino and Websphere products, but any web server you have in place that can retrieve AS/400 data in real time via any technology will work as it responds to a web page request from the IIS program written by the NT people. The terminology is do a Get from within NT web server processing (in CGI or the equivalent) of a specific web page URL on the AS/400 web server IP address and poulate the form input fields with data recieved in the page being processed. The AS/400 sends the page with data and the NT programmers put that data where they want in the web page being processed in IIS or use it for whatever processing needed to complete the page. This all happens extremely fast. If not, look at a fast AS/400 web server like Strategi. Also, the data is retrieved and processed on the AS/400 with RPG. Again, if it isn't fast, blow off the IBM marketing people and write some real code. Regards, Ralph ------------------------------------------------------------- Is Strategi really needed? Sorry for being so clueless here, but does Strategi run on NT or on the 400? I am guessing it runs on the 400, and if so, can we use NetFinity instead? NetFinity was installed to run with Domino (so that it could communicate better with M$ products like Excel and Word). Can we use NetFinity without interfering with the other (Domino) application? Also, in NT lingo, what do I ask the NT guys for? Will they understand what I want if I tell ask them to "send a page to the AS/400 from within the IIS CGI?"

J.Pluta

10-02-2000, 11:29 AM

I don't see the coordination between the systems as any more complex as coordinating message layouts. The pages served by the AS/400 web server are defined in one place and stored in IFS. They are independent of the design of the web pages served by IIS. The coordination of web page form field names for the AS/400 web pages is in the CGI in IIS and the Strategi script. Neither the IIS web pages nor the AS/400 RPG server programs are aware of the AS/400 web page particulars. Well, in a PUT request in HTML protocol, data is passed between the browser and the web server via a set of "name=value" parameter pairs. The "name" portion is the name of the field in the HTML form. So, let's say we have an input field named "CustomerNumber" on my AS/400 web page. If this is displayed to a browser, and the user enters a value of "123" into that field, then the data is returned to the web server as "CustomerNumber=123". Now, if an NT program (or any other program, for that matter) were to attempt to emulate an end user and "stuff" a customer number into the appropriate form field, the only way it could do it would be to send the same "name=value" pair to the AS/400 web server. This is what a lot of portal programs do, in effect "wrappering" one HTML web page inside of another. To do this, you have two options: you can name all your fields in your NT web page the same as your fields in the AS/400 web page and just blindly pass data from the browser back to the AS/400, or you can write code to handle each and every NT page that actually pulls out the NT field and "renames" it before sending it to the AS/400. For example, if your field name on the NT box is "Cusno", then in Java, you would do something like: session400.putValue("CustomerNumber", sessionNT.getValue("Cusno")); Nothing particularly difficult, but there's a degree of mapping that's involved here. Not only that, the AS/400 web page should have a 1-to-1 relationship with the NT pages, unless you have some serious mapping algorithms in your NT program. As you say, this is roughly akin to messaging, mapping the fields of the NT page to the fields of a message, except that you now have the limitations of HTML to work around for your messaging. But if it works, it works. I would view it more as retrieving key transaction data via HTML than wrappering the original web page. The IIS programming also retrieved data from local SQL Server databases and some other programming under NT. The AS/400 data was merged with data from the other processes in real time to serve pages back to the requestor. By the way, do these web pages do any posting (that is, does an HTML POST to the AS/400 web server actually update a database)? If not, then I'm even more confused as to why the HTML interface to the AS/400 was needed at all. If you're already doing SQL, then you might as well have chosen stored procedures (note that I'm not a big fan of stored procedures, but for strict query situations they can work nicely). But all of my discussion is based on my bias towards simpler things using as little middleware as possible; your solution is geared more towards the "component" design which takes prefabbed architectural pieces and integrates them into a working solution. As long as the approach works, and is maintainable and scalable, then it's a valid way to go. Joe <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-02-2000, 07:42 PM

"Nothing particularly difficult, but there's a degree of mapping that's involved here. Not only that, the AS/400 web page should have a 1-to-1 relationship with the NT pages, unless you have some serious mapping algorithms in your NT program. As you say, this is roughly akin to messaging, mapping the fields of the NT page to the fields of a message, except that you now have the limitations of HTML to work around for your messaging. But if it works, it works." Either field names or field offsets have to be coordinated to handle data exchange between two systems. If variable names for HTML form input fields (or whatever web people call them) can be used in the Post and Get syntax of a language, then I would have an externally maintained mapping table to transfer data from field x to field y. In other messaging protocols, the names may be internal, but the offsets for those internal names have to be kept synchronized. That holy grail of messaging, XML, is processed by looking for names that must be kept in synch between two systems. No matter what XML technologies exist for translations, there's nothing that would be done for this situation that a table driven mapping scheme wouldn't handle. As I referred to earlier, there was more going on with the IIS web pages than data retrieval from the AS/400. Only a subset of the fields entered by customers were passed on to the AS/400 for real time processing. Other processing was done at the same time against a local SQL Server database and some local programming. If a particular web page happened to have a one to one correspondence with the AS/400 web page, that was just a coincidence. By the way, what limitation is there in sticking text in an HTML field instead of in a message data structure field? "By the way, do these web pages do any posting (that is, does an HTML POST to the AS/400 web server actually update a database)? If not, then I'm even more confused as to why the HTML interface to the AS/400 was needed at all. If you're already doing SQL, then you might as well have chosen stored procedures (note that I'm not a big fan of stored procedures, but for strict query situations they can work nicely)." The Strategi web server looks up a script file corresponding to the web page name (same_name.hsm instead of htm), concatenates the data from form fields specified in the script, and passes them to a server program specified in the script. The servers sit on a receive dataq like call and wait for input. Server programs can be written in any language, and the jobs web site backend I wrote this year had ILE RPG, RPG III, and Java servers taking calls from web pages and from each other. For example, an opcode I wrote in one ILE server to send e-mail, or any number of other business processes, may have been invoked directly from a web page, another server, or any other AS/400 program for that matter. As you have advocated, Joe, calling RPG server programs leverages code, skills, and speed. The difference here is that the Strategi web server is directed to call a program via a script external to the web page HTML code, versus specifying a Java servlet in the HTML code which may then call an RPG program. It's not the overhead I'm referring to, but the hardcoded logic within the HTML. Pages being served to the public and designed by professionals needn't be clobbered with inserted call logic and version controlled with the web designers. The server programs do business processing as usual on an AS/400. On the one hand, the web pages were for customers and did not require an intense business processing interface, but a friendly customer interface instead. On the other hand, customer order entry and service can require some intense internal business processing if done in real time, as I did. I use record level I/O instead of SQL, but then I also believe in performance versus lowest common denominator technologies. Sending a web page to the Strategi web server and causing an RPG server program to be invoked and then getting the web page response takes two milliseconds on an internal network. It would take some serious I/O or starting up standalone AS/400 programs from the server to slow this reponse down. In addition, neither the web page nor the RPG program have any references to technology in them. The web pages coming from another web server are sparse, generic HTML text with form tags, and the RPG program is a dataq like processor that cases on a message type. There was no SQL involved, no ODBC, no RPC, so there was nothing that leveraged a stored procedure call and made sending a web page an unnatural act. In any event, the Strategi invocation of an RPG server is light years faster than a stored procedure call. "But all of my discussion is based on my bias towards simpler things using as little middleware as possible; your solution is geared more towards the "component" design which takes prefabbed architectural pieces and integrates them into a working solution. As long as the approach works, and is maintainable and scalable, then it's a valid way to go." I consider this use of the web server and Strategi's scripted invocation of server programs to be cleaner than coordinating sockets calls, much more powerful than ODBC and stored procedure calls, and much less complex than messaging middleware like MQSeries. Joe, does your PBD solution require a web server as IBM does with Websphere, a proprietary server as ASNA and Delphi/400 do, an open sockets interface, or what? Ralph

J.Pluta

10-02-2000, 08:42 PM

Maybe I'm just having trouble understanding you, Ralph. For example, I have a hard time reconciling these two statements: "Neither the IIS web pages nor the AS/400 RPG server programs are aware of the AS/400 web page particulars." -and- "Either field names or field offsets have to be coordinated to handle data exchange between two systems." Either the NT programs know the AS/400 web page field names, or they don't. In this case, they must, which invalidates the first statement. Whether this coordination is in a mapping table or not is inconsequential, because rather than the NT program change, instead the mapping table has to change. But that mapping table now becomes something that needs to be maintained as part of the NT web page. QED, the NT page is bound to the mapping table, which is bound to the AS/400 web page which is in turn bound to the Strategi server. And then this sentence: "Pages being served to the public and designed by professionals needn't be clobbered with inserted call logic and version controlled with the web designers." With JavaServer Pages, pages aren't clobbered by anything except calls to Java objects. The data is gathered by a servlet, placed into a Java object and then passed to the web page. Here, the binding is the method name rather than the field name, and that allows some pretty powerful manipulation; in fact, it's quite easy to have a Java object generate some of the more complex HTML and further reduce the burden of the web designer (though that's not necessary, and indeed some designers like to work with all the complexity, but the beauty of JSP is that you can do it either way). "I consider this use of the web server and Strategi's scripted invocation of server programs to be cleaner than coordinating sockets calls, much more powerful than ODBC and stored procedure calls, and much less complex than messaging middleware like MQSeries." Interestingly, that's exactly what I consider a message-based protocol to be: simple yet robust, without the added cost or overhead of the Strategi software. It also removes the inevitable problem of being tied to a vendor and thus stuck to whatever the vendor's chosen e-strategy is. "Joe, does your PBD solution require a web server as IBM does with Websphere, a proprietary server as ASNA and Delphi/400 do, an open sockets interface, or what?" The revitalization architecture is 100% open-source and works with any web server that support servlets and JavaServer Pages. It will run on a Linux server with Tomcat just as well as it will run on as AS/400 and WebSphere. It requires no third party products, and will run on a vanilla AS/400. And it's all free. Joe <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-03-2000, 07:19 PM

Joe, You may have a point concerning my statement that the IIS served web pages have no knowledge of the AS/400 served web pages, that is HTML code in one referring to the other. I think my statement is correct when I said that the NT IIS CGI level code is the place on NT that does refer to the AS/400 web page form fields, and it is a matter of an IIS web page invoking processing on the page with the equivalent of calling a CGI program. The CGI program matches the IIS and AS/400 web page fields, as I pointed out, and the HTML of the pages from both servers contains no reference to each other. If there is something wrong with my statement, please explain it. You translated my words "IIS web pages" to "NT programs". That mystifies me, to say the least. Unless it's impossible in IIS to invoke CGI or the equivalent to process a web page, where the CGI or equivalent can read from the incoming IIS web page and perform an HTTP transaction to another web server, you would have a point, but I doubt it. You do not refute my assertion that mapping by either field name or field offset is required for any messaging technology used. Therefore attacking the mapping within the NT CGI for this approach is attacking the mapping for every messaging technology that exists. If you explain to me how the mapping, however done, be it hardcoding or table driven, is a requirement above and beyond any other messaging technology, then I will consider you to have a point. I don't think you do. You say that your web pages aren't clobbered by anything *except* calls to java objects, acknowledging that indeed the HTML produced by page designers is clobbered. My statement that they needn't be clobbered is complete and correct, and AS/400 java programs can be and are called by Strategi to process web pages when so scripted. The script is external. I wouldn't base the whole argument for this solution on the externalized program calls from the HTML, but again my statements are simple, straightforward, and correct, and describe a simple, fast, and cheap solution that is processed by any mix of programs in any language on the AS/400. The fact that the Strategi web server is scripted to make these calls for each web page versus the HTML calling java servlets executed by Websphere and the like is not an overriding concern to me. They both accomplish the same thing. But again, the NT CGI program and the Strategi script contains the references to web page form field names. The IIS served web pages do not contain any references to the AS/400 web pages, the AS/400 web pages do not contain any reference to IIS whatsoever, and the AS/400 programs do not contain any references to either web page. This doesn't make my solution superior to using Websphere and java servlets, but the point was addressing you questioning if I what I said was possible. I cited a real case. The NT and AS/400 guys, the customer, preferred to deal with HTTP technology. The NT guys considered the HTTP Post and Get calls to be trivial to implement, and had only to get a list of web page field names in the pages being retrieved from the AS/400 to implement coordination. The AS/400 guys had no technology API's to implement whatsover, their input and output was through a dataq. You consider sockets code or RPC or some other messaging to be less overhead. They didn't. If socket calls programming and message format coordination is so simple, then why is Susan asking for suggestions on retrieving AS/400 data in real time? They considered sockets and RPC, and so did I with the customer, and yet both the NT and AS/400 guys preferred this solution to your suggestions. The vendor issue is valid. They have been around a long time in the AS/400 world, have a very fast and inexpensive web server, and you don't have to write a line of Java code or eRPG to implement a web site. Websphere is much more expensive, requires much more AS/400 hardware to give the same performance, has a learning curve, and does not seamlessly connect unmodified web pages and RPG programs to each other, where writing a java servlet is defined as not seamless. Writing a script in a text file and placing it on IFS along with web pages with their web site tool means you don't even have to enable IFS to the network. Having NT be the public interface to the Internet and passing page information to the AS/400 web server via another page acknowledges the reality that NT is what companies are going to serve with anyway, as well as their concern about exposing their production AS/400 to the Internet. I am as much an advocate as anybody of a small AS/400 web server accessing production files via DDM, provid ing bullet proof security, but web people don't want to work with the AS/400 and companies making these decisions won't even consider it. That's reality. If Advanced BusinessLink went belly up the day after you received the Strategi product, you would already have it installed and serving webpages with data processed in your RPG programs before that. Installation is literally 15 minutes. I implemented this solution with the customer in one day. Ralph

J.Pluta

10-03-2000, 08:09 PM

Ralph, this discussion has gone on long enough, I think. You're a vocal Strategi advocate, and I think the Strategi solution is an excellent one. I will certainly keep its design philosophy in mind when I create my next generation of software, which is the client/server version of the server/client technology I've already released to the public. I won't use your technique of double-mapping through HTML, but the idea of a scripted approach to servers is wonderful - it's very much like the configurable processing of SSA's original Sales Order Management architecture (SOM, not COM). My beef was that Strategi isn't the right solution for everything, and I just think your passthrough idea from an NT webserver through CGI to a Strategi web server through a script to servers is overkill, when the NT CGI programs could simply call a server directly. The fact that you'd rather add another layer of overhead than program a direct solution says something about the management of the project. But hey, it works. No harm, no foul. I still don't advocate vendor software for applications. Never have, never will. If I don't have the source to it, I don't like to use it to design my business rules. But that's a personal opinion, and that's why I loved the Series/1 so much - even the operating system was coded in a high-level language, and was user-maintainable. The decision boils down to this: using a scripting language separate from the user interface, or embedding calls to the business logic in your user interface. There are valid arguments either way. Your way provides a lot of flexibility, but at the price of locking yourself into the Strategi software. The servlet/JSP architecture is all open-source, but you have to learn how to code JavaServer Pages. It all depends on the final business decision. If it's cost-effective and maintainable and fits the user's needs, then great. I'd never propose your solution, but it met the need, I guess. Joe BTW, I get the idea that you think I'm proposing using the PBD packages as opposed to Strategi. That's not the case. The servlet/JSP approach doesn't need any PBD packages at all. The PBD packages are designed to put EXISTING green-screen applications directly on the web with almost no modifications. Strategi doesn't do that; it uses servers. If you already have servers written that communicate via data queues, then using them in a servlet/JSP architecture is trivial. A few dozen lines of wrapper code for the data queue communications and a simple ServerProxy class written in Java, and you're done. <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

nycsusan@hotmail.com

10-03-2000, 08:41 PM

Joe wrote: "My beef was that Strategi isn't the right solution for everything, and I just think your passthrough idea from an NT webserver through CGI to a Strategi web server through a script to servers is overkill, when the NT CGI programs could simply call a server directly." How? How can NT CGI programs call a server directly? (I hope you are including AS/400's in that.) And how do I communicate that (what verbiage) to the NT guys who want nothing to do with the AS/400? Even a URL or a book would help. Joe wrote: "If you already have servers written that communicate via data queues, then using them in a servlet/JSP architecture is trivial. A few dozen lines of wrapper code for the data queue communications and a simple ServerProxy class written in Java, and you're done." What if you don't have servers that communicate via data queues? How trivial or non-trivial is that to set up? And where could I find documentation on this wrapper code for the data queue (which I presume runs on the 400) and the ServerProxy class written in Java? I was waiting for you guys to wind down your debate before I raised (actually "flailing" is more accurate) my hands up in the air with quesions! You raise interesting points, and I would very much like to investigate your ideas as well as Ralph's. However, I need more details to do that. If you have the time to fill in the blanks for me, even if it's just to a website(s), I would appreciate it. Thanks.

nycsusan@hotmail.com

10-03-2000, 08:44 PM

Ralph, Thanks so much for all of your time. Although this is all WAY over my head, I am following (and printing these posts off) with great interest. Thanks again for all of the details! Sue.

Guest.Visitor

10-03-2000, 08:51 PM

Susan, I just read about everything a person might want to know about technologies that might fit a particular situation. Are these selected customers analyzing this data or are they just looking at it for reference? It seems fairly simple to use your favorite page creation and serving technology (I should have qualified resources as knowledge and experience) and a data server on your AS/400. That server could be written in SQL, RPG, Java or ?. This sounds like this may be historical data that used for analysis. If that is the case, reformating the data and storing it in something other than a relational database may make sense. Another possibility that Joe mentioned is ODBC, which may work just fine, but with a lot of connections and small requests may eat up more than its fair share of system resources. For SQL to work effectively, you may want to bypass ODBC and use a custom server program. David Morris

nycsusan@hotmail.com

10-03-2000, 09:12 PM

David wrote: "I just read about everything a person might want to know about technologies that might fit a particular situation. Are these selected customers analyzing this data or are they just looking at it for reference?" Both really. Each customer can view their own account. I am probably misunderstanding your question. To begin with, it will be view only, if that's what you are asking. No updates from the web, at least not yet. But according to my boss (and I am supressing a really sarcastic comment here) these "transactions coming from NT might initiate a job on the 400 or send the data someplace else" I think what he means is that something on the 400 has to interpret what NT sends. David wrote: "It seems fairly simple to use your favorite page creation and serving technology (I should have qualified resources as knowledge and experience) and a data server on your AS/400. That server could be written in SQL, RPG, Java or ?. " The trick here is that due to corporate politics which cannot be circumvented or changed, a group of "NT guys" will build the website on their server. They don't know the i400 (or whatever it's being called today) and they don't want to know the 400. David wrote: "This sounds like this may be historical data that used for analysis. If that is the case, reformating the data and storing it in something other than a relational database may make sense." What do you mean by something other than a relational database? Do you mean ship subsets of data up to NT on a regular batch (nightly?) basis so that the web queries are not really hitting data the 400? I was thinking of that myself. I don't know if the customer will go for that, there's a chance that they may want real time data David wrote: "Another possibility that Joe mentioned is ODBC, which may work just fine, but with a lot of connections and small requests may eat up more than its fair share of system resources. For SQL to work effectively, you may want to bypass ODBC and use a custom server program." Okay, can you recommend a place for a complete NEWBY to begin looking into creating a custom server program? And what would be too big for an ODBC connection? I am not sure (because my boss isn't) how summarized the customer data will be. Our legacy system retains a LOT of detail, and we process from 5 - 10 million transactions per day. We definately won't put anything close to that on the web, I am just mentioning it as an example of how much data is available. Let's say Company XYZ has 10,000 records to retieve. Is that too big to use OBDC? If so, is that when you would recommend the custom server program? Thank you your thoughts, David. I apologize for being downright DUMB about this, but I have never had to deal with this before. God help me. I am stuck between an NT group who has the political clout to call ALL the shots without even having to pretend they have a clue about the AS/400, and my managers who will promise everyone and their brother that the world will be delivered yesterday. It will take an act of congress to change the delivery date despite the fact that the requirements are still very nebulous. I am trapped in a Dilbert nightmare!! :-( Thanks again for your ideas. Sue

Guest.Visitor

10-03-2000, 10:14 PM

Susan, From what you have written, it sounds like something like Net.data and JSP are out because it is unlikely that the NT people will support it. More likely they will ask want to use active server pages (ASP), Cold Fusion, or something similar. To get data directly from the AS/400, they will also probably be more likely to want to retrieve data using ODBC. One request for 10,000 records is a good fit for ODBC where 10,000 requests for one record is not. If the data is used for analysis, you may want to look into a data warehousing solution. I bet that would provide much more capability than is necessary for this application. Data warehousing solutions are more expensive up front, but the capabilities are much greater than a static view. If this sort of thing fits the rest other needs, it may be worth looking into. I have used several products that could provide data in a variety of formats including reports, pivot-table, and drill down inquiry. David Morris

Guest.Visitor

10-03-2000, 10:53 PM

Joe, home brewing some code that reads/writes to dataq's on the AS/400 using some component would actually do the same thing as Strategi (besides web serving) in a simple environment. The NT guys had no interest in interfacing to Java, and in fact a JNI interface using some third party product would have had to be researched, and also that inserts the dreaded vendor specific solution into the equation. You say that JNI interface would be open source? Sun didn't do it with their multimedia JNI interface product.....free, but not open source. Wonder why, especially when we're not allowed to consider solutions from vendors who don't give away their code. Imagine that.....programmers trying to make a living. Scalability is a problem with your RPC/dataq solution, and if you don't write to dataq's then RPC called program startup time is a problem. Strategi launches multiple iterations of server programs as needed and parcels the stateless web page requests to available servers. Home brewing RPC calls or third party AS/400 dataq component interface calls means home brewing managing multiple server instances, distribution of requests to available servers, and tracking request responses to the web page it came from. Remember, I said any web server could be used, not just Strategi. I mentioned a couple of Strategi features, but said that any web server that can access AS/400 data in real time could be used to implement my solution. Managing scalability is a huge issue, and IBM pins all that on Websphere, BusinessLink on Strategi. I don't recommend home brewing a professional website, not for scalability and not for amatuer hour HTML code generated from programs instead of professionally developed web pages. But hey, that says something about the way I manage projects, doesn't it? No, I didn't think you were requiring PBD, just Websphere and java servlets, although I did ask you if PBD required Websphere or a proprietary server ala ASNA or an open sockets interface. I'm still wondering, if you could tell us. Strategi does require that one write at least one server program (they provide ILE RPG, RPG III, C, and Java server shells - you just fill in the routines that are cased to by comparing to message names you make up and use in the script) that cases on the incoming message type of your creation, process it, and then write a response back out into a buffer. The processing could be performed by calling an existing program should the program perform exactly the logic you want and nothing else. This would be much more modular than usually exists in an AS/400 shop or in vendor supplied packages in RPG or COBOL. I've found that client/server API implementations are much more granular than nearly any AS/400 program we would have, and that rarely would the exact logic sequence be just the way you want it. What happens in reality is the same as when code is written in java... existing business logic is lifted in a more granular form than currently exists. Ideally, as with the solutions you propose, Joe, this work will form the basis for a company business logic set of API's that are interface independent and can continually be built on. Also, I agree that part of that independence is that the servers can be called from Strategi or a Websphere Java servlet. The Strategi program name for reading/writing to servers could be used for a generic java servlet invocation program (the Strategi has a few message parms and a 10k message buffer). The program could be placed in a higher library list and the server program be called from a Websphere servlet and Strategi simultaneously for that matter. The web pages and API's are stateless. Also it could be one Java servlet which could be presupplied for that matter. Ralph

Guest.Visitor

10-03-2000, 11:17 PM

"How? How can NT CGI programs call a server directly? (I hope you are including AS/400's in that.) And how do I communicate that (what verbiage) to the NT guys who want nothing to do with the AS/400? Even a URL or a book would help." Susan, jsut going from general reading, I haven't done this stuff, but Remote Procedure Call, or RPC, a TCP/IP protocol like FTP, or stored procedures called through an SQL interface such as ODBC are the two common methods I read about. Another commonly suggested technique is putting a trigger program on a file and performing a SQL statement on the file which invokes the program. Speed and scalability are the issues. Almost anything will work for trivial applications. "What if you don't have servers that communicate via data queues? How trivial or non-trivial is that to set up? And where could I find documentation on this wrapper code for the data queue (which I presume runs on the 400) and the ServerProxy class written in Java?" You write them. A loop calling RCVDTAQ and SNDDTAQ with some case logic in between is all it takes. The magic is in architecting a robust messaging format and business logic API's.....repeated requests for data transfers as with subfiles.....keys being passed that let you position and continue. Many non-AS/400 programmers can only deal with SQL and a result set.....too many records? automatic cutoff after x number of records....that's why we're business programmers and they're not..... "I was waiting for you guys to wind down your debate before I raised (actually "flailing" is more accurate) my hands up in the air with quesions!" You'd have to be pretty patient, wouldn't you? :) Ralph

Guest.Visitor

10-03-2000, 11:29 PM

"Ralph, Thanks so much for all of your time. Although this is all WAY over my head, I am following (and printing these posts off) with great interest. Thanks again for all of the details! Sue" If it's over your head, I haven't done a good enough job explaining it. Considering all options may be complicated to understand in detail, but my suggested solution requires no more explanation thatn what I have provided. It is truly that simple and yet that robust. I have lost a lot of sleep lately, but I am trying to write these posts in between some messaging with others. So if what I say seems disjointed and incoherent, it is......:) Ralph

Guest.Visitor

10-04-2000, 12:09 AM

"What do you mean by something other than a relational database? Do you mean ship subsets of data up to NT on a regular batch (nightly?) basis so that the web queries are not really hitting data the 400? I was thinking of that myself. I don't know if the customer will go for that, there's a chance that they may want real time data " This is what most do because they can't do any better. Silos FTPing files around once a day because of ignorance and parochialism. This is why most web sites are not integrated with the back end business processes. This is also being recognized as an unacceptable view of your company. Trust your boss.....you need a solution with real time data. "Let's say Company XYZ has 10,000 records to retieve. Is that too big to use OBDC? If so, is that when you would recommend the custom server program?" SQL through ODBC is frequently configured to cut off at 2,000 records or less. You have to consider what the business process is. You're delivering data for display in a web page. How many records can be displayed in a web page? It's just like subfile processing. If you can't provide real time processing in groups of small set of records in key order, then the alternative is supplying a large set of records which the NT guys would have to wait for while the customer is waiting, store locally in SQL Server, then process a group at atime because you can't. They will quickly tell you to FTP a file once a day and stay out of their way. I wrote a jobs website backend, and at no point was I concerned about how many jobs or resumes met the search criteria. Are you concerned how many records could be displayed in a subfile program? The same concepts apply in messaging, via any protocol but including the web page protocol that I proposed. Part of the data transferred back and forth is previous and forward key values and a forward/back flag that you look at to decide what key to use to position with and what direction to read. Strategi includes sample canned solutions with these algorithms in them. The NT guys may or may not cooperate fully in carrying this data in their web pages, but they will respect you for being able to provide real time data in any way needed. Especially beware the people who try to steer you into trivial SQL result set solutions because you have "view only" requirements, at least for now. Those solutions do not provide a foundation for real time business processing. When you need to do that the inquire only solutions are no longer applicable. I still say your solution is only days away if you get a Strategi web server and tell the NT guys to send you web pages. The rest is just the same ODBC abd RPC stuff repeated over and over as if it were gospel, even though it's slow and not scalable. Scalable means that your initial solution was successful and more people want to use it, but it can'r handle more people. Scalable is not just a funny word. Later, Ralph

Guest.Visitor

10-04-2000, 04:19 AM

Scalability is a problem with your RPC/dataq solution, and if you don't write to dataq's then RPC called program startup time is a problem. Hmmm how is the startup of a CGI any better ? Message based architectures are the most scalable implementations. Basing on data queues will not cause scalability issues. We recently bechmarked using the AS/400 to serve requests from internet using data queues - over 70,000 business transactions (response time 1.5 seconds) an hour on a small AS/400 !!!! Needles to say the NT web simulator ran out of steam well before this - in fact it took 8 NT simulators to drive it breaking point. My preference is to use MQ over Data Queues, as they give much better transactional control and multi-platform. Also if needed the webserver can act independently of the application. Also MQ triggers can be used to automatically increase servers as requests are queued. Does Strategi handle transactional control - if so at what point ? It would seem to me lost with the double webserver unless the CGI developer has a confirm message that feedback to Strategi which feedback to the application to tell it to commit the database transactions. Is there anything in Strategi that helps with state management and persistance or is it the responsibility of the application server ? Home brewing RPC calls or third party AS/400 dataq component interface calls means home brewing managing multiple server instances, distribution of requests to available servers, and tracking request responses to the web page it came from. I dont think so ! The key, as you wrote later, is having a well thought out message architecture. With this you can run N stateless servers on one input Data Queue sending replies back to one keyed output data queue (The keyed dataqueue will handle the matching request to reply). David

J.Pluta

10-04-2000, 07:15 AM

Susan, Ralph has done an excellent job of outlining the requirements for a server system. They include three basic types of programs: Database maintenance servers. These are also sometimes known as CRUD servers for their basic functions (Create, Read, Update and Delete). CRUD servers take the place of files in a web application; rather than writing to a file, you call a CRUD server with a CREATE opcode. Query servers. These are more complex versions of database servers, but are read-only. Depending on your requirements, these servers provide access to not only the fields in the primary file, but also fields from dependent files, derived fields and summary fields. In this they function much like SQL. On the other hand, they can also provide data in multiple formats, such as when returning header/detail information. This prevents transmission of duplicate header information. Order and selection criteria should be supported as needed. Batch requests. These are simply requests to run programs, with or without parameters, synchronously or asynchronously, and optionally return the results (requests must be synchronous to return results). While this isn't the entire spectrum of client/server requests, it covers more than 90% of what you would ever need in a typical transaction-oriented client/server environment. There is also an entire subclass of work required to process spooled files, a special requirement that most people forget about. In fact, that's what prompted my CPYSPLFPDF program. CPYSPLFPDF was the first fruits of the work I've done in designing a complete client/server architecture. As Ralph points out, you can attach to the AS/400 from NT in a variety of ways, from sockets to RPC to stored procedures. However, none of these ways is simple or straightforward, which is why Ralph's webpage communications technique was so valuable in his situation. Coding HTML GETs and POSTs is a lot easier than some of the other techniques. But that's why I love servlets and JSP; once you have servlets, that means you have a JVM, which means you can use IBM's Java Toolkit for the AS/400, and a whole new world opens up to you. Access to the AS/400 through the Java Toolkit is very easy, from directly calling programs to reading files to accessing data queues. As Ralph said, there are a lot of complex issues here; now that the server/client book is published, I may have to set my sights on a client/server book to do the same for that architecture. Joe <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

J.Pluta

10-04-2000, 07:26 AM

No, I didn't think you were requiring PBD, just Websphere and java servlets, although I did ask you if PBD required Websphere or a proprietary server ala ASNA or an open sockets interface. I'm still wondering, if you could tell us. <smile> I guess you are tired, Ralph. From a previous response: "Joe, does your PBD solution require a web server as IBM does with Websphere, a proprietary server as ASNA and Delphi/400 do, an open sockets interface, or what?" The revitalization architecture is 100% open-source and works with any web server that support servlets and JavaServer Pages. It will run on a Linux server with Tomcat just as well as it will run on as AS/400 and WebSphere. It requires no third party products, and will run on a vanilla AS/400. And it's free! <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

nycsusan@hotmail.com

10-04-2000, 07:43 AM

Joe wrote: "Ralph has done an excellent job of outlining the requirements for a server system. " Yes, he certainly has, and I appreciate his help very much. But now I am little confused. I guess I misinterpreted your posts because you seemed to be shooting down Ralph's suggestions. That is why I asked you for more details about your ideas. If you feel that Ralph's suggestions were good, then why all the back and forth between you guys? Or has the debate worn you down and you have given up arguing? :-) Really, I thought you were disagreeing with Ralph most of way, but I guess I misunderstood. Thanks for the clarification, Joe. I appreciate the time that you, Ralph, and David have spent helping me.

J.Pluta

10-04-2000, 08:26 AM

"Yes, he certainly has, and I appreciate his help very much. But now I am little confused. I guess I misinterpreted your posts because you seemed to be shooting down Ralph's suggestions. That is why I asked you for more details about your ideas. If you feel that Ralph's suggestions were good, then why all the back and forth between you guys? Or has the debate worn you down and you have given up arguing? :-) Really, I thought you were disagreeing with Ralph most of way, but I guess I misunderstood." <laughing> The approach of mapping one or more server calls to a message request is in general a good idea, Susan; it serves to reduce the binding between the client and the server. My problem with Ralph's approach is twofold. First, passing through HTML from one web server through another is an added complexity that just doesn't need to be there - having to run and maintain two web servers where one would do is simply goofy to me. Second, I don't like sticking a proprietary piece of software right in the middle of my business application. If you happen to hit a bug (or "design limitation"), you are STUCK unless the vendor decides to fix it. I became more conciliatory when I realized what Ralph was up against: an entrenched NT bureaucracy with a lack of NT-to-AS/400 connection skills. In that case, the added complexity and overhead of a convoluted HTML approach may be "justified" by the fact that it will keep the NT people happy. However, this is a political, pragmatic solution, and a VERY bad precedent... in effect, you're saying that the NT people decide the architecture of your system. And frankly, NT experts, while often good at network configuration, are rarely very good at business application design. So, I wanted to make sure that it was clear that while the Strategi solution was indeed quick and made the NT guys happy, it was a kludge and architecturally I found it unsound. A little clearer? Joe <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

nycsusan@hotmail.com

10-04-2000, 08:52 AM

You? Conciliatory??? I thought that the moon looked a little BLUE last evening! :-) Joe wrote: " ... when I realized what Ralph was up against: an entrenched NT beauracracy with a lack of NT-to-AS/400 connection skills. In that case, the added complexity and overhead of a convoluted HTML approach may be "justified" by the fact that it will keep the NT people happy. However, this is a political, pragmatic solution, and a VERY bad precedent... in effect, you're saying that the NT people decide the architecture of your system. And frankly, NT experts, while often good at network configuration, are rarely very good at business application design." What RALPH is up against?!?! I am up against it too, that's why I am begging for ideas from you guys! For the record, I brought up the "politics of NT" in my 2nd post, and I think Ralph mentioned it a time or two as well. I think we all agree that the politics of the situation stink and they shouldn't drive the solution, but we have no choice. That's life in corporate America. We have to work within the constraints they place upon us! Joe wrote: "A little clearer?" You betcha ... like Waterford crystal! :-)

Guest.Visitor

10-04-2000, 09:25 AM

Richard, I would not recommend that someone do anything until I understand what they are trying to do. Detailing several strategies should help Susan. I personally would rather use our AS/400 for everything, but it is not the best tool in all cases. Shipping the data off may be a viable solution (cheaper, more functional, etc.) Integration with back end systems is certainly the ideal, especially when the flow of data is bi-directional. It seems as though Susan is describing a very simple inquiry, if the next phase adds more functionality, then I would look at this differently. Without all of the facts, which would require more than a few paragraphs in a discussion formum, it is impossible to make an informed decision. The bottom line is that ODBC may work just fine. We have used it for very similar applications and it is certainly simple and worked great. We have also used it for applications where it was not the best fit. From what I have read, the customer may just be looking for an invoice image. If that is the case, nothing suggested fits the need. If the customer needs to analyze the data, an OLAP solution may fit. If transactional integrity needs to be ensured, a messaging layer may fit. "Especially beware the people who try to steer you into trivial SQL result set solutions because you have "view only" requirements...". I would beware anyone trying to sell an expensive solution if all I need is a trivial SQL result set solution because of my view only requirement. David Morris

Guest.Visitor

10-04-2000, 08:32 PM

I brought up the "politics of NT" in my 2nd post, and I think Ralph mentioned it a time or two as well. I think we all agree that the politics of the situation stink and they shouldn't drive the solution, but we have no choice I think Joe and Ralph actually had the same architecture suggestion, which is to build the AS/400 into a Service Orientated Framework Provider. The diagreement is more over the implementation. If you build the AS/400 to deliver application services then you can quite happily handle other platforms such as NT or UNIX connecting. For instance an NT IIS web admin is likely to be very happy building pages using ASP. And from ASPs you can execute OCX or ActiveX components (such as the DataQueues provided in client access) or ODBC data access. You should also be prepared to deal with the UNIX/LINUX Apache Web Servers who are most likely happy with CGIs or Java Servlets. I believe the majority of the web servers in corporate businesses are UNIX based. My Opinion What you should be looking for is to prevent business functions and data being moved to the web server. You should be looking to put that on the central business server (in this case the AS/400) Why ??? Because what you are building should be re-usable services. They should be able to be re-used as the business expands. Example We had a bank introduce Telephone Banking (Customer needs AccessID & PIN), we expand to introduce Internet Banking, we expand again to introduce Mobile Phone (WAP) banking. Each time we can re-use the Customer Authentication on the AS/400 server, there is a single limit check service that can be reused etc. It allows the front-end (Telephone is WinNT, Internet is AIX, WAP is Solaris) developers to focus on what they know best. It reduces user testing since the business rules servers are not changed (e.g. Invalidate the ID if 3 consective wrong PINs) With no additional software the connections to your AS/400 can be: Data Queues (Client Access APIs for Win32 or Java Classes) Stored Procedures TCP/IP Sockets ODBC/JDBC - direct data access. Something which goes against the concept of a service framework. SNA (Dont laugh !! As additional security I know sites that only allow SNA connection from Internet Web Servers) HTH David

nycsusan@hotmail.com

10-04-2000, 09:43 PM

Thank you David, I doubt the "e" group will propose UNIX or Apache. They seem to have a cookie cutter, one size fits most approach. I think I even saw an "NT" label on their cutesy little diagrams too, so it looks official to me! :-) Today I almost lost my lunch when I got my mitts on a document with a few of the requirements. Talk about a FLUFFY document, YEESH! Lots of verbiage, but with very little substance. Certain things did make me perk up ... for example, in "phase 4" (don't ask me what happened to phases 2 and 3 'cuz I just cannot imagine) they want to allow customers to view and pay their invoices over the web. I don't know what that changes, if anything, in your suggestions. This is the first I have heard of the update capability being mentioned. For this first phase, a customer should be able to download their file of data (which in this case is rated telephone calls). For large customers, CONNECT:Direct will be used. "Large" is defined as customers with more than 25,000 records in their file. There is no upper limit to this file, it could be over a million records, and they will have a new file each and every day. I am still waiting for my boss to respond to my questions about the requirements in this document. They are way too vague to do much about. In the meantime, I shall dive into the manuals and research all that you and Ralph have suggested. I want to learn more about this even regardless of this project. Thanks again for all of your ideas!

Guest.Visitor

10-04-2000, 11:02 PM

David Bye wrote: "Hmmm how is the startup of a CGI any better ?" I agree, David. 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. As I posted yesterday, response time from one's server program called by Strategi to process a web page to the time it takes to get the page back on an internal network is 2 milliseconds. This is extraordinarily fast, but then BusinessLink isn't pushing a generic product that just happens to run on the AS/400 too, such as Websphere and Domino web servers. I agree that messaging through an AS/400 dataq is extremely fast. My memory is shaky on this, but I think I remember that we can have multiple copies of a program receiving on the same dataq, effectively letting OS/400 manage distribution to available servers instead of Strategi doing that. I have been around large scale implementations of transactions fed to the AS/400 from NT, and they have been very successful as you point out. The downsides are minimal. A third party Windows component must be chosen to read/write the dataq's or IBM's product installed. A messaging format must be laid out and programmed against on both sides. These two downsides are not what you and I and Joe would call downsides, they're normal interoperability requirements, but the political climate that Susan and I faced was not conducive to implementing the solid engineering needed to do this. Whether it seems petty or not, the web page HTML was a non-intrusive, easily understood mechanism for exchanging data with a minimum of cooperative programming required. Just the field names of what data would be exchanged. If you think that an NT IIS CGI programmer would prefer to write a message to a Windows component and handle the response to be integrated back into the web page and delivered to the customer versus posting the same info via HTTP and integrating the response into the web page, then I won't quibble. Given the beligerance of the NT programmers, the point was to avoid AS/400 specific technologies. It just gave them an excuse to say they weren't interested in dealing with an AS/400 dataq communications component or interested in agreeing on a messaging format with the AS/400 people. You have to remember, their goal is to get processing off the AS/400 and into SQL Server. Data exchange via HTTP is innate to their IIS processing, and so is stuffing form fields in CGI. On the other hand, that is dealing with a petty environment, and some NTer's may prefer a messaging format sent through a COM component. As I said to Joe yesterday, the Strategi server programs are written in a RCV/SND dataq like loop and could process through a dataq as easily as through Strategi. Either an internal name would be used which passed the parms on to Strategi when applicable, or Strategi's command name would be used in the library list for a program that read/write's the dataq's on the AS/400. The scalability issue comes up on a home brewed scheme to distribute messages not only to an available instance of a server, but to various server programs. For focused applications, one dataq with a dedicated server that can parse out the work to handle all the message opcodes is sufficient because the scope is narrower. For a web site, whether the pages are served by IIS or the AS/400, the number of opcodes to handle a website of web pages could be extensive. The programming of the servers may be in different languages. The jobs website had servers in ILE RPG, RPG III, and Java. Either a different dataq would have to be established for one or more instances of each server program, or a home grown threaded distribution system for messsage handlers would have to be written. You want to make that argument to others, be my guest. I tried MQSeries for real time messaging within a large corporate environment two or three years ago. MQ bogged down badly. We ended up writing a home brewed DDM distribution system to distribute transactions to all the AS/400's. Fast as lightning and well understood so as to handle failures well, not that we had any that I recall. Delta uses MQ for real time transactions, and had to put an AS/400 dedicated to handling MQSeries at each site, this according to articles on their problems in ComputerWorld at the time. I would no more use MQSeries to message while customers are waiting on their web page response than I would use snail mail. Commit/Rollback? I've never used it. Haven't seen it in BPCS, MAPICS, PMSC, JDA, Infinium, JBA, or JDE as used by Fortune 100's. There is a common perception that MQSeries provides such a thing when in fact the manual goes to great lengths to dispel that myth. What is done in your code around MQ API calls can be done in your code around any API calls. Assured delivery? That stuff is peachy in an offline corporatewide distributed environment. Web sites are funny in that they're both more and less demanding. The speed must be there, but if there's a timeout, resubmits by the user or a CGI program is acceptable in that environment. I myself wouldn't try multiple transactions across more than one web page in a stateless commit environment. A commit to update three files for an inventory transaction simultaneously? Like I said, ERP's have been updating files in sequence since the dawn of time. What, an I/O is going to fail? So we rollback, and tell the customer? I think if we were to go to the troubl e of defining rollback points then a commit can be done regardless of the messaging system. Strategi is mostly just a web server versus an application server. Any state that is desired to be retained must be stored with access by a transaction key, usually carried along in the web page, but Strategi does provide for sign in security, like this forum does, and if used there is identification information and state information available with each web page delivered to a server program. Nothing that couldn't be done with your own files, but they standardized that aspect of it as a way of making it easier to look up where we're at in the process and continue processing. Thanks, David, for some thoughtfil questions. Hope my answers and yours and Joe's suggestions lead to helping us all deliver some great software for the AS/400. Ralph

Guest.Visitor

10-04-2000, 11:10 PM

The revitalization architecture is 100% open-source and works with any web server that support servlets and JavaServer Pages. It will run on a Linux server with Tomcat just as well as it will run on as AS/400 and WebSphere. It requires no third party products, and will run on a vanilla AS/400. And it's free! Can't add anything to the ultimate.......:) Ralph

Guest.Visitor

10-04-2000, 11:18 PM

""Especially beware the people who try to steer you into trivial SQL result set solutions because you have "view only" requirements...". I would beware anyone trying to sell an expensive solution if all I need is a trivial SQL result set solution because of my view only requirement. David Morris " Websphere is free with the AS/400, I believe. I'm not selling anything, just for the record, David. Regards, Ralph

Guest.Visitor

10-05-2000, 01:16 AM

For this first phase, a customer should be able to download their file of data (which in this case is rated telephone calls). For large customers, CONNECT:Direct will be used. Large is defined as customers with more than 25,000 records in their file. There is no upper limit to this file, it could be over a million records, and they will have a new file each and every day. Ekkkk.......(thats my term for they are crazy) Suggesting ConnectDirect be installed on the remote sites....whos paying for that ? Sounds like IT Data Centre solution to me - it makes operations life easier, and bogs everyone down into a piece of software. Security will be interesting - how to ensure client A does not pull client B data. (I know have unique object rights for each file !!!:)) What if your company accidently send client A client B data ? Other options ?<ul> Pushing the file using email Publish the file onto a webserver allowing clients to pull the file Real Time message feeds to the clients - making the information more realtime and allowing business processes to improve accordinginly. [/list] they want to allow customers to view and pay their invoices over the web. Nothing too new here. This is a standard bill presentment and payment system. Call Oracle, Netscape Sun Alliance. How you link to a bank/s is a number of variations. Sounds like a fun project that needs some more thought in the design stage. David

Guest.Visitor

10-05-2000, 02:49 AM

Richard, I didn't realize that you were suggesting WebSphere as a replacement for SQL. You are correct, the Standard Edition of WebSphere is "free". I have spent quite a bit of time this year working with WebSphere, I can tell you that there is actually a substantial cost. David Morris

Guest.Visitor

10-05-2000, 09:11 PM

Hello Susan, We have a very easy-to-use alternative for you, however it does require a commercial product, so those who don't want to read this message, close your eyes right now :-) We recently introduced a new product called Active Server Pages/400 (ASP/400) which allows you to do the following from an NT IIS web server script: - Read/Write AS/400 Files Directly - Call exising program logic (COBOL, RPG, CL) and pass parms bidirectionally. - Submit remote commands - Communicate with AS/400 data queues Because you're using IIS and Active Server Pages, the AS/400 never touches the Internet. All AS/400 communications takes place between the AS/400 and IIS. Best of all you can continue to create RPG and COBOL code that your web scripts can call via Javascript or VBScript. We also have a live demo on our temporary web site. We're in the process of upgrading to a T1. The demo hits our AS/400 170 system via IIS. The IIS web server is a Pentium 200. Check it out: Link to live demo: http://rjssoft.dyndns.org/scripts/asp400samples/asp400.asp For more information, contact me via email or telephone or check out our web site. Regards, Richard Schoen RJS Software Systems Inc. "The AS/400 Report and Data Delivery Experts" Email: richard@rjssoft.com Web Site: http://www.rjssoft.com

Guest.Visitor

10-05-2000, 09:16 PM

David Morris wrote: "I didn't realize that you were suggesting WebSphere as a replacement for SQL. You are correct, the Standard Edition of WebSphere is "free". I have spent quite a bit of time this year working with WebSphere, I can tell you that there is actually a substantial cost." 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. While the NT people politically manuever to offload processing onto SQL Server, I say just proceed with web development anyway. So what if you're serving to an IIS web server who's serving to the world. All one's development for this on the AS/400 is with e technologies and the company will soon see that an AS/400 can serve as well as or better than IIS as they shove pages back and forth to each other. At some point the company just may move those pretty picture web pages to IFS and be good to go. I recommend BusinessLink Strategi as the AS/400 web server, simply because I've used it extensively and it's tuned to delivering AS/400 solutions by programmers who still care about performance. If someone wants to go with IBM's generic dogs, that's their problem. But I'm not selling Strategi, and I'm not recommending a solution that requires one to buy something. On the other hand, should one choose Strategi, there is no learning curve required to put up a web site and deliver professional web pages with integrated data processed by one's own AS/400 programs... and not those HTML renderings of some green screens or rolling your own HTML code on the fly either. Professional web pages, developed by those your company will choose to do that work anyway and integrated with your AS/400 data by you without modifying their work. 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 we b pages, then maybe I'm the only one who noticed... but I doubt it. Ralph

Guest.Visitor

10-06-2000, 03:24 AM

Susan, My first thought after seeing your request was, why don't people get a clue and just let the AS/400 - the best web application server on the planet provide the solution. But, then Ralph introduced an innovative solution that I had never considered, and over the course of a debate was able to iron out most of the confusion. Its too bad the people he worked with in Chicago weren't here to give more details about their IIS CGI work. Actually, it was a surprise to hear that Windows CGI was being used under IIS since Microsoft highly recommends Active Server Pages or their ISAPI interface over CGI. CGI starts a new process under Windows and is considered to limit scalability and performance. One point of confusion for me was Ralph's terminology about client programs sending web pages to a web server. To be more precise, web clients send HTTP requests as opposed to web pages to the web server, and the web server usually responds by sending a web page back. But don't let that detract from what is probably a great idea - to pass the request from the NT web server to the AS/400 web server and let an AS/400 program respond. Joe raised his concerns about an extra layer of overhead with a middleware product like Strategi, but Ralph did a good job of justifying it in his discussion of Stragegi's features and scalability. Besides, we tend to think that a strait data queue interface between NT and AS/400 is less overhead, but we forget that they require an installation of Client Access on the NT server (has a de-stablizing effect), and a queue server on the AS/400 that is itself a middleware layer which forwards the entry to a user written application. Not to mention that the NT guys probably want nothing to do with them. Dave Bye made mention of the WININET.DLL. You should probably look into it. It provides a high level interface (easy) that would enable a Windows program (VB, Foxpro, etc.) running under IIS to forward HTTP requests to the AS/400 and receive the response. The response may then be passed on to IIS. Both ASP and Window's ISAPI interface provide an easy way to extract the HTTP request (including form variables) from IIS. And, WININET.DLL provides an easy way to forward them to the web server on the AS/400 - be that Stragegi, or the default HTTP server that comes with the box - which BTW can forward to Websphere if you like the idea of a Java Servlet rather than an ILE program responding. The key thing to remember is that the AS/400 web server gets a standard HTTP request by this technique. 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. I'm glad objections were raised about the performance and scalability of ODBC, JDBC, RPC, and Database Triggers. Anyway, thanks to all for the great ideas discussed and debated in this thread.

Guest.Visitor

10-06-2000, 04:24 AM

I tried MQSeries for real time messaging within a large corporate environment two or three years ago. MQ bogged down badly. 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. Delta uses MQ for real time transactions, and had to put an AS/400 dedicated to handling MQSeries at each site, this according to articles on their problems in ComputerWorld at the time. I would no more use MQSeries to message while customers are waiting on their web page response than I would use snail mail. Interesting I've not heard of the MQ problems at Delta. I couldnt find any negative reference on the Computerworld web site. Do you have any more info ? Not that it makes a difference since of course every technology has bad implementations and exceptionally good implementations. The mix of a project has not changed over time its still people, process and technology. IMNSHO its the mix that makes the difference not just one aspect. There is a common perception that MQSeries provides such a thing when in fact the manual goes to great lengths to dispel that myth. What is done in your code around MQ API calls can be done in your code around any API calls. Yes you could write your own middleware but is that an effective use of programmers and technical peoples time ? Would not their time be better spent on helping program business solutions. This debate all comes down to worth and need for middleware. Sorry but I never mentioned commit/rollback its about transactional control. MQ is a message transport it is not a distributed transaction processer. It can be included in a distributed transaction environment (opps AS/400 doesnt have one of those !!). Using MQ features such as COMMIT/ROLLBACK, Confirm of Delivery, Expiration Times,Exception Message Processing you can build a close to complete solution. Most of this is not for application programmers so the code is wrappered into a simple interface. Most old (and even some newer) AS/400 solutions are built in a traditional manner with traditional users (internal staff) so the need to for additional transactional control is limited. However when building decoupled systems where the users are the general public....you want to implement in same way ??? Well I dont think this is going anywhere. But I did feel a need to put up a balancing view is case someone else reads this forum looking for feedback of MQ.

J.Pluta

10-06-2000, 10:24 AM

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: <INPUT NAME="Field" VALUE="Initial value" size=60 maxlength=256> 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 (<INPUT NAME="Data" VALUE="Initial value" size=60 > 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 <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

J.Pluta

10-06-2000, 10:36 AM

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 <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-06-2000, 11:52 AM

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

10-06-2000, 12:26 PM

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

10-06-2000, 12:30 PM

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 <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

J.Pluta

10-06-2000, 12:39 PM

And I saw your repsonse after I responded to you earlier response <laughing>. 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 <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-07-2000, 10:37 PM

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 <quote>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. </quote> 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

10-08-2000, 03:44 AM

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

Guest.Visitor

10-08-2000, 09:04 AM

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

10-08-2000, 10:02 AM

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

10-08-2000, 10:58 AM

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

10-08-2000, 11:31 AM

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

10-08-2000, 12:11 PM

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

10-08-2000, 01:01 PM

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

10-08-2000, 05:15 PM

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

J.Pluta

10-08-2000, 07:27 PM

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. <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-09-2000, 03:42 AM

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

Guest.Visitor

10-09-2000, 05:59 AM

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

J.Pluta

10-09-2000, 06:36 AM

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 <a href="//www.java400.net?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJ vkG9"><img > 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</a> - where the AS/400 speaks Java with an RPG accent Home of PBD2.0 (//www.zappie.net/revitalization?phpMyAdmin=MzvdqLOMiN7HL4yz2OU82BJv kG9), the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

Guest.Visitor

10-09-2000, 09:48 AM

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.

Guest.Visitor

10-09-2000, 10:48 AM

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/http/services/Apache.htm Mark Phippard

Guest.Visitor

10-09-2000, 12:51 PM

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.

nycsusan@hotmail.com

10-09-2000, 04:51 PM

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.

Guest.Visitor

10-09-2000, 10:14 PM

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

Guest.Visitor

10-09-2000, 11:26 PM

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

Guest.Visitor

10-09-2000, 11:32 PM

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/http/services/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

Guest.Visitor

10-09-2000, 11:43 PM

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

Guest.Visitor

10-10-2000, 01:42 AM

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: VISA Electron (Debit Card) Authorisation Transactions CashCard (Smart Card Stored Value) Top Up Mobile Banking (WAP) inquiries Replication of data changes Corporate Banking Inquires Treasury Settlement PC Client Inquiry Terminals 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 <a > href="http://www4.software.ibm.com/cgi-bin/bookmgr/bookmgr.exe/BOOKS/MP42/3.1"> IBM AS/400 MQ report </a> 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."

Guest.Visitor

10-10-2000, 10:36 PM

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