web to 400 communicaiton methods

[J.Pluta]

web to 400 communicaiton methods

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 src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[Guest.Visitor]

web to 400 communicaiton methods

Joe, 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]

web to 400 communicaiton methods

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. src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[nycsusan@hotmail.com]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

"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]

web to 400 communicaiton methods

"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]

web to 400 communicaiton methods

"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]

web to 400 communicaiton methods

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]

web to 400 communicaiton methods

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 src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit

[J.Pluta]

web to 400 communicaiton methods

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. 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! src="//www.zappie.net/java/_derived/index.htm_cmp_zero110_vbtn_p.gif" width="140" height="60" border="0" alt="Java400.net - Java/400 Freeware" align="middle"> Java400.Net - where the AS/400 speaks Java with an RPG accent Home of PBD2.0, the color=red>FREE Java/400 Client/Server color=blue>Revitalization Toolkit