Strike It Rich! Reversing the Trend of Web Clients

[R.Daugherty]

IBM has one thing right. The user interface needed to be grounded in the OS, not floating above it as in Swing. So they did that with Eclipse and their OS based GUI interface, and donated their vision to open source, and that was a good thing. Now, what they have wrong. A user interface of the future won't be controlled by Websphere. It will be more desktop portal centric with sockets and other TCP/IP communications like HTTP to a variety of sources. The browser will be just another window in the portal suitable for what it was designed for, content browsing and hyperlinking. So what does this mean for us? I think 5250 emulation written in Eclipse with advanced GUI features that Dave and others have posted here should be the standard AS/400 interface that can be written to from within green screen development. That is, Websphere is not required. This is heresy to IBM and will never be allowed, but it continues to show that IBM sacrificed the AS/400 at the Websphere alter long ago. An AS/400 should be able to run with Apache open source tools with Websphere not required as every other server out there does. Instead, we are controlled by IBM because we are captive, and they can. rd

[J.Pluta]

You don't need WebSphere! Write your business logic as servers. Write your UI in whatever flavor you want. I like simple JSP Model II, which means I can run on Tomcat as easily as I can WebSphere. If you want thick client, use VB or Eclipse's RCP. It's simply stupid to wait for IBM to create a UI for you when there are already so many out there to choose from. Instead, you need to be concentrating on how to write servers. I've been saying this since the 80's, and I watch as it goes through various name changes (not unlike our beloved iSeries). Client/server, message-based processing, remote procedure calls, CORBA, COM/DCOM, and now the ubiquitous SOA -- it's all the same thing! Send a message to a server and get a response back. If you write your business logic THAT way, you can have WHATEVER INTERFACE YOU WANT! Joe

[R.Daugherty]

An interface has to come with the AS/400 that is the recognizable business processing interface that is currently 5250 green screen. The interface has to take the 5250 data stream as a subset but should be enhanced with an XML keyword superset that is programmably extensible. Web pages and thicker clients than the default client are special cases for customers and business partners or power users. In my opinion the default interface, shipping with the AS/400 and recognizable as the AS/400 interface and something that AS/400 programmers and shops have a clue is the new standard GUI interface, would be able to pop up the browser as a window and render HTML streams and provide a default rendering of the 5250 based stream if it receives the extended keyword stream. If we don't have that, no one much cares what we write as a server. You have to have someone who wants to be served, and that requires a recognizable AS/400 interface again. IBM was insisting it be web pages served by Websphere, and that as I've said over the years isn't going to cut it. I saw where IBM is extending their RoadMap or whatever, Joe. I hope your product is included as a sanctioned option! rd

[J.Pluta]

An interface has to come with the AS/400 that is the recognizable business processing interface that is currently 5250 green screen. The interface has to take the 5250 data stream as a subset but should be enhanced with an XML keyword superset that is programmably extensible. I disagree with this premise. The 5250 interface has stood the test of time as the perfect character-based block mode interface. Trying to shoehorn graphics capabilities onto it is lipstick on the pig. If you want to do that, my product is the better way to go. But that's not what I'm talking about. What is needed is a message-based interface that is UI INDEPENDENT. The UI layer, whether it's a 5250 or a browser or a thick client or a Dick Tracy wristwatch, should be completely separated from the business logic. When you design a server program, you should design it from the message, not from a UI standpoint. If I were to design the ultimate IDE from scratch, it would have three very separate pieces. There would be a server designer and a UI designer. But the primary piece would be a message designer which should work directly from a UML diagram. You define request and response messages, including meta-messages which combine one or more lower-level messages. The server designer is simply used to fulfill those requests. It has no UI requirements and is completely UI independent. I'd probably have a few templates that I would use to generate standard servers in the language of my choice. The UI piece, on the other hand, would be solely for designing a UI, whether it be browser, thick client, green screen, whatever. Whenever the UI needed to communicate with the database, it would do it via a message to a server. There are a few other pieces. You might need a configuration module that would identify the appropriate communication protocol, and you might also want an application control piece that handled the basic program flow (depending on whether your application was purely client/server or was more of the traditional server/client model). Design this interface, and make sure one of your server definition modules supports RPG. Package it with a low-end iSeries, and you've got the killer development environment: you can run a green screen interface, a browser interface with either Tomcat or WebSphere, or a thick client interface in either VB or RCP. Sure, you have to design the messages and the templates and eventually write code for the servers. You need to learn how to design your UI. But with that flexibility, you can write ANYTHING. But no, what everybody keeps asking for is a push-button development environment so they don't actually have to program. They want to drag database fields onto a grid and have all the work done by somebody else. They don't want to innovate, they want to replicate. And that's just stupid. Joe

[R.Daugherty]

I hope others can comment here. Maybe they see something I don't. I just see transaction buffers going in and out, legacy wise through EXFMT but still just a transaction buffer. I see the messaging and user interface as varying, should be independent of the app. A web page, 5250 screen, new AS/400 Eclipse Java interface, or even VB should all be able to handle the transaction buffers from the app with overriding of EXFMT formatting the transaction buffer appropriately based on what the AS/400 determined about the connection at signon including messaging protocol used through what kind of virtual server, etc. I don't see any particular difference based on interface being GUI. More control keywords, fonts, colors, maybe a link for downloading a graphic following a keyword with placement info, also an extra type attribute for text as to what type of control in which to display. All this I see done in a standard AS/400 DDS development, in other words, totally backward compatible to 5250 green screen. Current green screens would get 5250 binary, new interface would get XML keyword equivalent with extra control attributes. I see the 5250 with full mouse, windowing, and menuing as baseline but Eclipse Java new AS/400 interface with additional GUI capabilities such as graphics, fonts, colors, interoperability with desktop apps, perhaps builtin Gecko HTML rendering, etc. The extensible program defined keywords would clue a rich client with what class to use to process following text but a default component would be used in a dumber client. It's just an extension of what we already do, but made interface independent at the EXFMT level. The only reason IBM doesn't do it is because it wouldn't use Websphere and that is apparently verboten. Even when I wrote an interface independent server for JOBS/400, a server for web pages but which I tested with green screens, it wasn't all that complicated. I just read and wrote dataq's, and who read and wrote back the dataq's and what they did with the data was transparent to me. I see the 5250 transaction buffer as being that dataq buffer. There shouldn't be any reason why our programming can't be rendered to several different interface types simultaneously with appropriate formatting by OS/400. I know IBM can do it, they just won't unless they can figure out a way to require Websphere. Plus the IBM marketing hooeys have designated the AS/400 as some kind of SAN or something for lightweights as if they never heard of thousands of huge companies that run their business on OS/400 and RPG. But again, I hope others comment because maybe they see more in your tiered development approach than I do. rd

[J.Pluta]

But again, I hope others comment because maybe they see more in your tiered development approach than I do. I advocate a tiered architecture where you can write the UI independently of the back end, with either side using whatever language skills you have most prevalent. You want IBM to extend a 30-year-old architecture to provide a subset of GUI capablities within the old 5250 paradigm. Joe P.S. The latter is already done, by the way. My product (http://www.plutabrothers.com/PBDWeb/p1.html) does it, and so does WebFacing. The extended keywords are comments in the DDS.

[David Abramowitz]

Joe Pluta wrote: The 5250 interface has stood the test of time as the perfect character-based block mode interface. I will disagree with this statement from the aspect that the within the confines of 5250-land there is a great deal of room for improvement. I am saying this regarding a character based interface. As far as 5250 graphics are concerned, it was proven over twenty years ago that the 5250 data stream could handle graphics. There was just no follow through, or further development. I suppose that no one at the time thought a graphical interface was important to computing. Dave

[J.Pluta]

I will disagree with this statement from the aspect that the within the confines of 5250-land there is a great deal of room for improvement. There's no room for improvement that makes any business sense. By business sense, I mean something that will sell to more people than you and Ralph. I suppose that no one at the time thought a graphical interface was important to computing. If people had bought it, IBM would have sold it. The point is that nobody wanted a graphical 5250 interface, and whether it might make sense now is moot because there are already better, more established graphical interfaces. Joe

[David Abramowitz]

If people had bought it, IBM would have sold it. If memory serves, the price for a dumb terminal was $6,000. There's no room for improvement that makes any business sense. By business sense, I mean something that will sell to more people than you and Ralph. Stick to the issue Joe. If you disagree with a statement say why. Personal rancor will get you into deep smeg, and quite frankly invective is beneath you. Dave

[buck.calabro@commsoft.net]

> I hope others can comment here. Maybe they see something I don't. Throwing down the gaultlet, eh Ralph? :-) As you might imagine, I have some thoughts on the matter, and you've provided the perfect introduction: > I just see transaction buffers going in and out, > legacy wise through EXFMT but still just a transaction buffer. The problem is subtle, but it's there if you dig it out. The transaction buffer is an analog for the UI. That is, we have designed the UI and the program to operate in lock step with each other. The buffer exactly matches the DDS, and the RPG program is very intimate with the specifics of that buffer. Change the UI (DDS panel) even a little bit, and the program changes too. What the rest of the webby world is doing dissociates the UI panels from the program logic, in a way that we have never done with RPG and DDS. DDS is a unit-record interface: read a card, write a card. > I see the messaging and user interface as varying, > should be independent of the app. A web page, > 5250 screen, new AS/400 Eclipse Java interface, > or even VB should all be able to handle the > transaction buffers from the app with overriding > of EXFMT formatting the transaction buffer > appropriately based on what the AS/400 determined > about the connection at signon including messaging > protocol used through what kind of virtual server, etc. And they can do exactly that, if you intend to tie yet another generation of panels to the logic in the program. I can hear you thinking 'What IS he going on about? How can you possibly have a display panel that isn't tied to the program logic?' One way is the Java Bean. The HTML asks for a field at will by embedding a bean in say, a Struts page. The panel has no tie to the logic other than saying 'get me the account name.' The program doesn't pass out a pre-formatted buffer; it returns an account name. Or address, or... > It's just an extension of what we already do, but made > interface independent at the EXFMT level. The only > reason IBM doesn't do it is because it wouldn't use > Websphere and that is apparently verboten. IBM already DOES do this exact thing, and they call it WebFacing. We think of DDS as a mere formatter; to make the punches on the card more readily readable. But the output is still a card, with the account name going right here before the address and after the account number. Very much tied to the logic of the program, where you chain to this file to get the address, that file for the credit rating, another file to get the product history and then bundle it all together to write a card. Changing the way the card interpreter runs is not the answer unless you need a grey screen. That is, a 5250-looking display that's browser grey instead of 5251 green. Beans is only one answer; you can certainly use data queues to serve up individual fields if you want to, or even entire buffers. It's a question of just how much freedom to give the UI guy. In our past (and I mean you and me and others who've been doing this for a decade or more) the UI was simple to do because it's just a fancy looking card, but modern apps want real GUI stuff; drag & drop, clickable dropdown thingies, user-adjustable colours and fonts - you name it. They want to re-arrange the screen by telling an intern to fiddle with the page and not have to pay a programmer big bucks. I hope I managed to get across what I'm thinking; that fancying up DDS isn't enough for what the end user expects today. --buck

[R.Daugherty]

A good discussion, but I am puzzled. Webfacing is mentioned. I said formatted at the EXFMT level to several different types of interfaces simultaneously based on connection. That at a minimum is 5250 binary, 5250 XML superset, and HTML. It would be done in EXFMT to HTML if the cnnection is HTTP. There are of course a zillion commercial options, which is the whole problem. You have to have a standard interface to write to like we have now with 5250 green screen for the AS/400 to continue to exist. Otherwise the AS/400 and whatever IBM calls it in the future will die when the last green screen dies. I disagree that the full 5250 capability as baseline is insufficient or even marginal. In fact, the full 5250 with mouse, limited colors, windowing, and menuing is pretty much feature complete for an interface. It's just a matter of whether the messaging is formatted in 5250 binary, 5250 XML superset, HTML, or something else. Typical reaction is why not HTML then? Reason is all the things you listed buck. The new interface should be OS grounded Eclipse Java 5250 emulator with all the features you mentioned. They are all independent of the XML keyworded transaction buffer. If someone drags the fields around, the keywords still map to the components. If it's permanent, the new layout would have to be stored with the users profile, but that kind of flexibility is what I'm talking about with a new interface. One thing I mention everytime but which probably doesn't get understood is interoperability with desktop apps or to other systems through sockets. This is critical and the future. Browser HTML is an island from the desktop. So is Java Swing without a JNI infrastructure to write to. The new interface must be drag and drop interoperable with other desktop apps, and an OS grounded UI is critical to that. IBM provided that with Eclipse Java and the new interface would be open source written in that. But all that is irrelevant unless IBM does the formatting in EXFMT. 5250 development has all the necessities of transaction processing. Everything we do can continue to be displayed in 5250 green screen as well as HTML or the new Java interface. It's just a matter of additional user functionality that they can do amidst the transaction processing, in parallel with our transaction logic. And we must not forget, it is that lockstep transaction logic which makes our programming so solid. It should not go away, the user should just have more capability in interacting with other apps to be as productive as they can be on the desktop. The new interface should also include a spreadsheet (IBM had Lotus rewritten in Java modules long ago) that works directly against AS/400 data. There should be no copying of data and working offline. I am not posting against anyone else's solutions. I am saying this is a necessary evolutionary step that IBM must take to keep the AS/400 viable, a standard recognizable AS/400 interface that ships with the system and everyone knows they can write to using current development methodolgy. I doubt that IBM prefers that the AS/400 dies, but they are ensuring its demise with their lowest common denominator cross platform Websphere strategy. They may even be so silly as to not want to cannabalize Client/Access sales, who knows, but the AS/400 requires what I describe for companies to continue to write software for its unique capabilities. rd

[J.Pluta]

Dave, nothing personal about it at all. It's my opinion that you're asking for something that nobody else wants except you and Ralph. Nothing rancorous about it. If you can find people who agree with you, then I'll happily admit I'm wrong, but the reality is that the vast majority of people who want a graphical interface will use a real GUI rather than an extension of 5250. There is no market for a graphical 5250 data stream. Joe

[David Abramowitz]

Joe Pluta wrote: the vast majority of people who want a graphical interface will use a real GUI rather than an extension of 5250. This is true, and I will agree with it. How about this now: The vast majority of AS400 programmers if given enhancements to 5250 capabilities will use them. Dave

[J.Pluta]

I don't think so. I mean, we've had graphics forever (remember BGU?) and nobody jumped on THAT paricular bandwagon. And while we've had the "GUI lite" features of DDS for some time now, they're not exactly high adoption techniques. Heck, there aren't that many people using the help text capabilities, and those are really well done, in my opinion. No, I think the most green screen users want is consistent use of colors and command keys, without a whole lot of fluff. The ones who want GUI come frmo the Window world, and to them some half-implemented menus and radio buttons do not a GUI make. But hey, we can agree to disagree on this one. Let's see if anyone else weighs in! Joe

[buck.calabro@commsoft.net]

Hi Dave, > How about this now: The vast majority > of AS400 programmers if given > enhancements to 5250 capabilities > will use them. I don't know 5 iSeries programmers who use existing graphical functionality like MOUBTN. I'm afraid that's more typical than not. --buck

[R.Daugherty]

I agree with that. Windowing is used and I get asked about it in interviews. Mouse I haven't seen a need for, but a new interface should make function key buttons clickable anyway. Menuing I haven't used. You have to give people a reason to take their hands off the keyboard and onto a mouse to use a mouse, where getting "focus" may be a reason but not a productive one. A productive reason would be mouse driven interaction with other desktop apps such as drag and dropping data, resizing subfile table columns, clicking on a column to bring up a different read only view of the subfile sorted in the order clicked, etc. The main thing is to get a standard Java interface out there where a mouse can be used or not used, but if there's a productive way for people to use it then we'll program for it. rd

[R.Daugherty]

I'm going on the road again this morning, returning from a trip where I didn't get an RPG programming job yet again after more than a year. On the other hand, calls from recruiters picked up slightly after Labor Day and increased dramatically after New Years. I even thought I would get a paying job again. Oh well. If not for all my loans being in default, this is a wonderful opportunity for me. I got a book written that I'm proud of and I've almost completed rewriting my Double Deck Pinochle game in Java for use on internet game boards, just the start of a lot of ideas I want to work on. Are any of them an interface for the AS/400? No. I'll do a lot of experimentation on interfaces for my projects, the same as I'll be experimenting with replacements for DB2/400 and every other aspect of OS/400 that will no longer be available to me and people who will want to use my software. I will do my best to emulate it and have been researching on how I may go about it. I have a roadmap, as IBM would say. But the Java interface for the AS/400 must come from IBM, must be open source, must be formatted for along with HTML and 5250 in EXFMT by OS/400, and must ship with the AS/400 to be viable. Otherwise the AS/400 will be about as viable as my career. rd

[J.Pluta]

But the Java interface for the AS/400 must come from IBM, must be open source, must be formatted for along with HTML and 5250 in EXFMT by OS/400, and must ship with the AS/400 to be viable. What's sad is that the Java interface already exists and comes from IBM and is open source. It just isn't going to be implemented via EXFMT, and if you could get past that you'd be thrilled with what you can do on the box. Joe

[Guest.Visitor]

'How about this now: The vast majority of AS400 programmers if given enhancements to 5250 capabilities will use them. Dave ' I don't agree with this. I have been to many shops and DDS isn't exploited to the level it could be in not one. It is not the developers who are driving that decision, it is our customers. They (where I have been don't want fancy on their green screen, they don't want an abundance of colors, they want simple and easy for the old data entry personnel to continue doing business and not have to be retrained into something they don't want). They want everything to stay as it always has been (if we add a screen, they want to perform just as the other 999 screens do).......now on the other hand where they want new and fancy and a lot of colors they don't want it to look or feel like the 400 (and these are the same customers). They want it to function and look like windows (because thats what they want). And the ones that want, sign the checks, so the ones that do, do what they want, and they don't want enhanced DDS. So, we have been part of the problem, they don't want to be tied to a transaction, they want to click a mouse and get what they want no matter where they are in a transaction, and DDS and ExFmt are not the way to deliver it and 'they' know it. And so must the time come for 'us' to know it too. Show your hands, how many of you are working on enhancing your DDS on the clock or after hours? And how many of you are working on other things instead to try to stay employed? or on contract? This only counts if you are working on anything new, because there will be maintainance forever on RPGII and whatever else is old.

[Guest.Visitor]

When our users want green screen aps for data entry they don't want change. For the most part they are happy with 3 colors, White,Green, and blue. We have to fight with some of them to accept any change good or not. When they want new ones GUI stuff, Easy400 works great and they are happy with it. IBM's attempts at changes in the DDS produce crummy results in my opinion. That's why I don't a lot of the graphic features. On the S/36 I could write a document and have it show the values in a table file as a part of the help function. They ran away from that idea. They built all kinds of neat functionality into that word processor and then didn't tell anyone. Then the took it away because, "Nobody used it". Help text is nice, but unless you build a lot of detail into it, it is quickly out of date and useless. Having help is nice, but most shops I have worked in are more concerned about getting programs written than writing help. Radio buttons and the other attempts to add GUI items to the screen don't work on everything, and I don't like the way they look. I don't like the newest pull down menus. They are only a halfway attempt at GUI. I don't use them because I don't like their implementation. If they came out with a real GUI interface that looks good and runs efficiently, I would use it. Since I don't believe they are going to, I will settle for CGI & Java, using products like Easy400

[skemp]

I've used Mouse and Menus in interface design extensively in the past. A typical use is to provide menus which allow the user to filter the contents of a subfile, for example one drop-down menu may provide selection critea by product group and onother by order status. Mouse can be used to allow the user to click a column in the subfile to have the subfile sorted in that sequence. Granted, it's possible to do this using Function Keys (since MOUBTN emulates an F-Key anyway) but it's easier for the user to use the mouse than to position the cursor in the column and then press a function key. Giving the user the flexibility in both functionality and useability is the key thing. Stuart

[bharder@nlrha.ab.ca]

I have a strong feeling that tinkering around with the 5250 interface just isn't going to make very many people happy. It doesn't deliver the goods to the clients, and the administrative and financial types won't pay for it. The issue is far deeper than the simple appearance of the screens, too. Issue 1: 5250 is a proprietary interface, and it's very far from universal. The 3270 interface is similar, and from IBM, but obviously not exactly the same. The DEC world was all ASCII VT-### terminals, there were Wyse terminals and on and on. None became truly ubiquitous. The reality is that Windows is everywhere, HTML is everywhere, and you can make weaker cases for Mac, the various Unix/Linux GUI's, and so on. Issue 2: Location independence. The Internet has it, and people want it. Universal network connectivity is here based on TCP/IP. Sure, 5250 can be disconnected from it's SNA roots and routinely is these days. That's not the point. You want to be able to log in to your systems from any old computer with an Internet connection and a browser. Aha you say, our systems are inward facing and we only serve them up in corporate settings that we can control! Sure, that's what you do now, but have you ever thought it might also be the case that you can't do it any other way, so you never try? And when someone asks, you simply say no? Don't your staff ever travel? 3). Too many weird interface issues that decrease user productivity. The 5250 interface is mostly used in a way that's modal, but GUI's have shown the value of non-modal interfaces. I've even written 5250 stuff that's non-modal but the reality is that most software on that interface platform is modal. What business value did locking the keyboard ever provide? Have you ever tried to train a new user and needed to explain the Field- key? And how does anyone justify turning the rightmost digit of a numeric field into a } character? The client should enter the facts and the computer should worry about formatting issues. Automatically! I say that people will accept change that improves their work situations and their lives. Provide a clear benefit, explain it effectively, and you will get where you want to go. The thing is, that has already happened with graphical interfaces and universal networking. The public and business expectations have been raised to expect these new capabilities. Fiddling around with 5250 is closing the barn door after the horse has left. Sure, you can re-write everything using DDS keywords that are rarely used, or don't even exist yet, but you've exceeded the threshold of tolerance for change. The correct business approach under those circumstances is to say: If we have to change everything anyway, then let's really open it up. We have strategic needs that we would like addressed. The technology becomes secondary. What technology helps us to get the business power and flexibility that we crave? Most times, the answer list won't include 5250.

[buck.calabro@commsoft.net]

> And how many of you are working > on other things instead to try to stay > employed? I am. I don't know of any employer who will train me for new stuff on their dime. --buck

[R.Daugherty]

I read all the responses. Great to hear different opinions on this. I guess when I say XML formatted 5250 superset for the new interface it doesn't explain it very well. It describes what 5250 is doing on the green screen with keywords but would be rendered in Java or any other GUI interface driver programmed to respond to keywords, so for example, the way buttons and menus look in 5250 emulation is totally irrelevant. The menus and buttons would be rendered in the desktop OS look and feel provided by IBM's Eclipse GUI in a new interface. It would also render less than satsfactorily in a 5250 emulator if someone were using a 5250 emulator, in other words, totally backward compatible, but the point of a new Java interface is to render beautifully per desktop standards as we all would want and expect. The point is that they are all just interface commands, transmitted in 5250 binary, XML 5250 keyword superset, HTML, and any other format needed, provided by IBM in OS/400. We just direct in DDS. How well it looks on the desktop will vary based on the interface. The new Java interface should look and work like a Windows program in Windows, and IBM has seen to that with Eclipse and their desktop OS groundedd GUI. I am talking about modal programming, however. Event driven programming may be fine for some things but it hasn't proven to be fine for ERP transaction processing. Nothing I suggest prevents other types of programming, but client/server has largely been proven a failure for enterprise transaction processing. It has only been the interface that has been suggested to change for us, primarily from 5250 green screen to HTML web page. The XML 5250 keyword superset with extensible keywords would be an important breakthrough for AS/400 programming in my opinion. As keywords, it is largely irrelevant that they were designed for a green screen and in fact they of course wouldn't be transmitted to an existing 5250 binary emulator or terminal. The intent of the design, such as text field 1, would precede the data along with positional data on the green screen. A component in a GUI interface would be rendered in any interface receiving and transmitting the XML stream. In fact, I argued in my three IMHO columns on this that it would enable machine to machine transaction processing, and since then more wrappers such as SOAP have beome more dominant for this, but whatever the wrapper, even a faked 5250 session, the XML keywords opens our programming and our box to become what one would hope would be the predominant transaction processing OS, that is, OS/400. The flexibility , however, must be provided within OS/400 in EXFMT for solid RPG transaction processing that becomes interface independent on the fly. Others obviously disagree. Another thing I argued for in my columns was a companion sockets session with each interactive session signon. I think data drilldown is imperative, and I think the way to do that is to feed off the transaction screens and provide query views based on point and click at transaction data, and from there drill into as many views as desired. This in no way affects the original transaction logic which merely waits for a response but it does provide supplemental real time information to the transaction processor based on the same authority restrictions of the job being performed. If there is some fundamental interface component that is not addressed or implied by 5250 DDS, then let's add it to DDS and design for user interaction within transaction modal programming to any type of interface simultaneously based on connection type. I don't know of any aspect of an interface that isn't already covered, and what I describe is an orchestration of interface components rendered via XML to any interface programmed to respond. The fact that it is backwards compatible via 5250 binary and that all existing 5250 programming is forward compatible via XML wrapper keywords is also important, but not as important as how those buttons and menus look if no one wants to use it. The Eclipse Java interface would deal with both aesthetics and interoperability with other desktop apps that a browser doesn't. All we need to do is keep writing that solid RPG transaction logic and let it be rendered as desired. OS/400 would do the rest. rd

[MCWebsite.Staff]

0

[Guest.Visitor]

Buck, I do. chuck Opinions expressed are not necessarily those of my employer. "Buck Calabro" <starbuck5250@mcpressonline.com> wrote in message news:48C292A19ED65DE6C9BCE4BED7243549@in.WebX.Wawy ahGHajS... > > And how many of you are working > > on other things instead to try to stay > > employed? > > I am. I don't know of any employer who will train me for new stuff on > their dime. > --buck > >