** This thread discusses the article: The Year Ahead: Predictions for the iSeries Community **
Joe Pluta wrote: The browser is ubiquitous and thus the interface requires no additional software. This is one reason (among many) why the c/s model is a faulty premise just waiting for a conclusion. I agree that the browser provides a standard. Whether or not you can call that an interface standard or not is still up for grabs, but the browser as an I/O interactive comes with its own standards despite variations within browser choices. I disagree with IBM's approach to an AS/400 interface. There are at least five IBM tools to transform current running applications:
- [*]Webfacing[*]HATS[*]CA for the Web[*]Host Transform[*]5250 Gateway[/list]But none of these really provide an IDE from which native programs may be written. Here is my proposal or challenge to Toronto labs:
There's a lot you raise that everyone here probably has something to say about. You have stated the user interface philosophy often and implemented it. The user interface can range from a green screen through a browser through Java through a thick client. There are appropriate apps for all and it shouldn't matter when the infrastructure is there on the AS/400 to output to any and all of them. I think there's a call for a lower level infrastructure in our programming that builds in user interface independence, and it certainly would include something in OS/400 that overrides or multitasks EXFMT but also certainly not limited to that. It should be as common to the infrastructure as multiple languages are in an ILE program. It would be OS/400, not Websphere, and that's where IBM is letting us down, in my opinion throwing us to the wolves. But I digress. Here is the funny thing about all this talk about browsers being the intuitive business solution to replace the green screen. Windows is eating our lunch and they are doing it with thick, rich, powerful, real GUI programs. You don't hear all this nonsense about browsers from them. All you hear is the sound of chomping as they eat our lunch. IBM and people from IBM systems are the ones that talk this way, IBM with Websphere, and the IBM oriented crowd does it apparently because they come from a terminal screen background and see browsers as some kind of ubiquitous green screen that's white and displays text in different colors and fonts and sizes and sort of shows graphics in odd places, based on the whims of HTML rendering. Basically they see it as a substitute for a terminal. But you never hear the people that count, users, saying that that is the way to conduct their business transactions. They use real Windows programs with powerful components to do work that we can't seamlessly integrate with a browser or even a Java screen. I described such integration before that constitutes a real and productive desktop, but all that ever came from IBM was terminal oriented web pages. Meanwhile the successful ERP's had at least semi thick clients that integrated with desktop programs such as Office. Browsers are a perfect complement for accessing content, but anyone who has ever filled out a form in a web page should know that a web page is not the place to conduct internal complex business transactions. For that matter, I described a spreadsheet type subfile that would eliminate the ridiculousness of copying data to Excel, often to multiple spreadsheets, and working with it offline while the data changes even as they work. There may be something in IBM's Lotus spreadsheet code that works through Websphere against AS/400 data directly, but I haven't seen anyone talk about this natural use of working with data integrated with other AS/400 processing, something that is actually intuitive. Yes, Oracle and Peoplesoft did release browser based versions of their software, but I have seen nothing but kicking and screaming from the people that have to use it. Rich clients are eating our lunch because that's how you make a leap in productivity. The main problem with client/server is that the Windows people didn't know how to write business logic servers like we and the mainframers have done for decades and instead dropped their logic in inscrutable places behind buttons. The resulting mess was a catastrophe, but because of bad architecture, not rich clients. The subfile concept is the key to our success, and could and should have been extended to rich clients and office productivity programs such as spreadsheets, and browser web pages for that matter. The interface shouldn't matter. Centralized business logic and data does. We should have all those interfaces at our disposal, from one programming platform integrated with OS/400. Anything less is constantly churning AS/400 IBM product managers pushing the AS/400 as little more than a simple shell for Unix, Linux, and Windows, something nobody in their right mind in the real world would even consider doing. But that's what IBM has done to us. I started to pose a thought experiment of considering what browser interface app could be considered to have been developed more effectively than an equivalent system on the AS/400, and then I thought, dagnab it, no, one of these IT luminaries tell us of a system they did more effectively than we have, and I'll post this example for them to beat. I and another programmer designed and developed a jobs site, JOBS/400, that had every advanced feature found on job sites at the time, things like multiple resumes, multiple searches, instant matches on every posting with immediate email notification of a match of interest, matching within x miles of a city or zip code or by state or country, full text keyword search criteria, and browser administration by the site owner of job matching criteria to add or change any criteria that could be dreamed up at any time with no programming changes to web pages or files. How long did it take two programmers to sit down with the clients, a software vendor and competitive rag to this one, nail down the requirements, write it, test it, and deliver? Three months. From scratch. It ran without a crash for two years with maybe a dozen lines of code changed and no file changes. I challenge any webhead to beat that with any system of comparable complexity. How did we do it? With RPG. Sure, we did the admin server in Java with the AS/400 Java classes to showcase the flexibility of the system. There were ILE RPG, RPG III, and Java server programs all interoperating against web pages. But I tested every function of the servers with green screens. The servers didn't know or care what the display was, and they shouldn't. The key was RPG native I/O and subfile style programming. I assure you it was a ton lighter than Domino and could have handled any number of times more users than Domino on the AS/400 does, and that has been measured at more than 10,000 concurrent users. That should be our message, but instead very large corporations down to fairly small companies run day in and day out with efficient programs against corporate data, operations on data so large that an SQL just hangs, billion record files. But our story doesn't get told. It just keeps working quietly, untold. rd
Leave a comment: