What technologies interest my AS400 colleagues? [Archive]

Guest.Visitor

09-15-2000, 11:20 AM

Hi Jeff, You make several interesting points. Some random thoughts not necessarily directed to you: :) Most AS/400 package source code is still in RPG III, and I've seen no clear indication of a particular trend that will emerge in modularizing AS/400 ERP packages, much less re-architecting to an OO foundation. There are fits and starts, such as MAPICS abandoning an effort to CASE their product and being left with an orphaned SYNON Order Entry module, or EIS type modules being done in client/server with no practical integration to the AS/400 ERP code, or attempts to provide a client/server replacement ala JDE OneWorld or SSA AS/SET BPCS, but the typical shop neither has a vendor supplied replacement for RPG III code nor a clear indication of what a potential replacement may look like. It should come as no surprise then that if the vendors are scratching their heads and other body parts as to what to do, then RPG programmers are just as puzzled as to what to "play" with. The calls to play with anything for the sake of personal growth are unrealistic. There is precious little time to get the job done, and this concept that little side projects will be done using random new development languages such as ILE RPG, Java, net.data, etc. for the sake of prototyping and learning is not going to fly, no matter how often the mantra is chanted. I recently saw a guy with a Masters in Physics take up RPG, for the money, and write some solid business logic with it, while collaborating with an AIX wienie who just took up Java, for the money, and wrote solid AS/400 server business logic using the AS/400 Java Toolbox. Neither had known the AS/400 but both learned whatever AS/400 commands and utilities that were needed and used them. I've also been involved in the past in hiring smart people for a Fortune 100 out of both large and small schools in the last few years and seen them pick up RPG and go with it. Our pitch was that the business runs on that code, and they were the future. Of course we also told them there would be plenty of opportunity to do Windows projects as well, but there is smart new blood coming into AS/400 land, perhaps smarter even than those of us who got into this sorting punch cards. :) Speaking of smart, back in the PC assembler days in the 80's, most of the great hackers were American. I've noticed with both Java and the AS/400 that many of the smartest hackers are European, not necessarily that there's any link between the AS/400 and Java. Perhaps they are now smarter about everything? :) Looking at job ads recently, I've noticed a decent amount of need for Synon (Cool:2E ?) and a sprinkling for Cool:Plex. This was a technology that was hyped for years, so excuse AS/400 programmers for being somewhat leary of new technologies when they can look out at a graveyard of Cool:Plex projects, projects that embodies all that the graphical interface and OO proponents espouse, projects that were supposedly the future of the AS/400, and see massive failures and the company that fathered the remaining existing successful Synon projects as well as Cool:Plex repeatedly bought and sold and pillaged. Not only are there numerous incoherent architectural directions now, there are remnants of past orgies of cool technology drifting through our libraries. Excuse the AS/400 programmers if they don't jump on every nirvana that IBM floats out there, not as a coherent architectural vision but as a me too answer to whoever's eating their lunch this week. When IBM has as clear a vision for developing AS/400 apps that leverages the record level I/O competitive advantage of the AS/400 as the 5250 emulator, then we can choose an IBM or third party development environment and go with it. In the meantime, these calls to play with some new technology that has nothiing to do with the line of business RPG III software is a hoax. If you don't think so, try playing with Java or net.data and then approaching an NT or Unix shop and talking about a job. It is a hoax unless people understand that the OS is even more important than the language to shops, Java being cross platform not withstanding. It is also mindless to espouse vanilla Java with vanilla SQL through vanilla JDBC as some sort of we don't care what the computer is, here's the program. This is an IT fantasy that is light years away from real companies with real heavy duty data processing needs with real budgets who will stick with RPG native I/O programmers who deliver the goods everytime, IBM's fantasy to sell 20 times the computer to run a Java program also notwithstanding. This is not a Java flame. I've just seen too many CASE tool disasters that generated vanilla SQL I/O that were supposed to be the replacement for that old stodgy monolithic native I/O RPG. The only difference is that they generated C, sometimes allegedly C++. The name has changed, but the game remains the same, and I'm still waiting to hear if San Francisco will be the largest disaster yet or the final realization of that nirvana dream. Regards, Ralph

J.Pluta

09-15-2000, 02:17 PM

Ralph, not so long ago I'd have been rubbing my hands with glee at an opportunity to answer your eloquent if somewhat circuitous missive. I'd have prepared myself with some extra-strength coffee, then put hand to keyboard and responded point-by-point to your assertions. However, this is the kinder, gentler Joe Pluta, so I'm only going to comment on one point (that you made in two different ways): "The calls to play with anything for the sake of personal growth are unrealistic. There is precious little time to get the job done, and this concept that little side projects will be done using random new development languages such as ILE RPG, Java, net.data, etc. for the sake of prototyping and learning is not going to fly, no matter how often the mantra is chanted." -and- "In the meantime, these calls to play with some new technology that has nothiing to do with the line of business RPG III software is a hoax. If you don't think so, try playing with Java or net.data and then approaching an NT or Unix shop and talking about a job." <kawf> Well, Ralph, stop beating around the bush and tell us how you REALLY feel! <grin> Seriously, though, I have two fundamental disagreements with you on this issue. 1. For anyone who wishes to design new software and at the same time stay in the field for more than four or five years, it is absolutely imperative that they learn web enabling skills. Browser-based access is going to be a requirement for all business applications in the very near future, for a number of reasons, not the least of which is cost. By moving an existing application to batch and accessing it via browser, your hardware costs can be lowered by as much as two-thirds based on current AS/400 costs. I'm doing this today via my revitalization architecture, and many companies are looking at this as either an intermediate step to O-O or as their long-term user interface solution. And to do this, you need some sort of web UI skills, which today is best done using servlets and JavaServer Pages. 2. I didn't see anyone espousing "playing with something for the sake of personal growth", but frankly, if you want to be vital in this market, that's exactly what you have to do. Now, we've discussed many times on this board that there will be plenty of work for RPG III programmers for some time, but it's not likely to be anything leading edge. It'll be vitally important to the client, but it sure won't be anything exciting. I just finished spending 40 hours on a very involved sales analysis report for a client, and while it's absolutely required for his business, it wasn't exactly the sort of thing I want to do week in and week out. And that is exactly the kind of project that will be available for people with pure RPG III skills and nothing else. It used to be that RPG III was enough to be on the leading edge (I designed the client/server architecture for BPCS entirely in RPG III) but that's no longer the case. So it's a personal decision: stay current, or do maintenance. Now I don't think you're advocating maintenance programming as a career goal for everyone, especially not the people who frequent this forum looking for the best, the brightest, the most current solutions to their IT problems. The future is in web development, and the future of web development is Java. If you can't convince your company to do a side-job in Java, LEARN IT YOURSELF. It takes an under-$1000 computer and an Internet connection to get started in Java. I know, because that's how I got started. Not enough spare time? I understand that, especially in these quality-of-life conscious days, but frankly, if you don't want to go the extra mile, then be content with where you are. Personally, I think I've done enough maintenance programming. I'm willing to expend some of my free time to extend my knowledge set, stimulate my intellectual growth, increase my earnings potential and above all, have fun. Because if you really love programming, Java is the language to use. And if you DON'T really love programming, then anything I tell you is falling on deaf ears anyway. <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

09-15-2000, 02:31 PM

I agree wholeheartedly with the kinder, gentler Joe Pluta!

Guest.Visitor

09-15-2000, 06:18 PM

Hi Joe, As these threads about our future and the future of the AS/400 concern questions in the back of the mind of most AS/400 programmers these days, I think it's important to air the assumptions underlying the logic surrounding advice about development strategies. I know you and the others here are busy, and by no means would I do anything but encourage a programmer to feel the thrill of creating in a new more powerful way, but I have been listening to this same industry advice concerning the web and server side Java for probably three years now, and I think that most AS/400 programmers are still wondering what the heck after all these years. As for myself, I was in AS/400 R&D for three years prior to this year, actively searching for and evaluating AS/400 technology solutions and presenting prototypes of business solutions with many leading AS/400 commercial products. This is in addition to providing technical assistance to our BPCS, MAPICS, JD Edwards, Infinium, and Gentran package programmers, as well as sundry other tasks such as leading a conversion from IP addresses to DNS for a data center move of a dozen large AS/400's and implementing multi-site manufacturing with RF transactions processed across a WAN. At no point was I bored. This year, I just completed writing the AS/400 back end of a replacement for a major AS/400 jobs site using the Advanced BusinessLink Strategi AS/400 web server, with most of the server modules done in ILE RPG but with the admin server module written in Java utilizing the AS/400 Toolbox (by a Java programmer), and the zip code server done in RPG III, all co-operatively processing job site web page transactions with speed being the primary criteria. In my spare time, I am rewriting my Double Deck Pinochle program from assembler to Java. I say all this to indicate that I am not speaking from ignorance and denial, but from first hand observation. Although I have expressed doubt about the suitability of the browser to replace the 5250 emulator, I agree that your PBD solution, or the much more expensive Jacada Innovator solution, is the most powerful way of delivering existing green screens to either an emulator or a browser by replacing the EXFMT screen with an API call. Notice however, that this is a powerful, cost effective solution for the business which doesn't add web skills to a programmer's arsenal. Assuming one actually wants to process green screens in a browser, it's the right thing to do, but let's not delude ourselves that we now have any web skills out of that. Programmers need to understand we leveraged existing RPG code to deliver screens to a new medium, and that's all. It may help the business, assuming the screens work decently in the browser, but it won't help the programmer get a different job. I just finished writing the entire back end of a jobs web site, and I've never written a line of HTML or generated a line of HTML in my life. Am I ashamed? No. The presentation was isolated from the business logic. Web page designers who know nothing more than HTML, Javascript, and Cascading Style Sheets created the web pages. A scripting process in Strategi, that can be performed by someone with a macro writing level of capability, mapped data buffer fields between the web pages and the AS/400 server programs. With this approach, programmers don't write lines of code that generate HTML, web page designers don't insert calls to API's in the HTML nor hand it off to someone to perform that task later, and the scripter who maps data from buffers to fields neither must be a database programmer nor an artist. Isolation is what IBM preaches for going forward. They are right, but there are different levels of isolation. Writing separate programs that generate HTML isolates code function, not job function . I am aware that there are ongoing improvements in integrating designed web pages with dynamic data retrieval, some Microsoft specific, some Java specific, but an AS/400 programmer need not be ashamed to write business logic API servers that process messages regardless of the source, destination, or presentation of that data. It is powerful, cost effective, and leverages centralized business logic to any medium, but again has nothing to do with the web, Java, or ILE for that matter. To design and write API servers and accompish modularization of company business logic is a desirable achievement for both the AS/400 programmer and the company, but this will not get the programmer a different job. Writing GUI programs, ideally in Java, which access the AS/400 or not, is something every AS/400 programmer who wants to diversify or cover his bets should do, I agree wholeheartedly, and many EIS business solutions require this approach to be effective, so it is advantageous to both the programmer and the company to do this, Visual RPG, ASNA, Delphi/400, Java, or Microsoft languages with ODBC components all. I agree with you 100% that programmers should do it themselves for their own benefit and for their career should the company not want to task them to that, and benefit as they add those skills. However, I stand by my statement that dabbling in Java or net.data to produce some isolated business solutions is neither effective for the business nor helpful enough to one's career to actually get a job on another operating system. I believe that an AS/400 RPG programmer should incorporate prototyped subprocedures and, where appropriate, bound ILE modules and service programs, to transition from monolithic RPG programming to a level that adds value to both the programmer and the company. This is also the way that ERP packages will modularize when they do, in my opinion. I remain a skeptic that these ERPs will become web enabled and that people will accept processing data through web pages. GUI programs will blow them away forever. Regards, Ralph

J.Pluta

09-16-2000, 10:33 AM

Okay, I tried not to get too terribly sucked into this conversation, but there are too many mistaken assumptions in your response. It seems you read what you DON'T want to hear, and then respond, regardless of what I really said. ...but I have been listening to this same industry advice concerning the web and server side Java for probably three years now, and I think that most AS/400 programmers are still wondering what the heck after all these years. And that's our first issue. I never said a thing about server-side Java other than for application control. My preferred architecture is JavaServer Pages for UI, servlets for application control and RPG for the business logic. And actually, the back end language choice is dictated by the client's expertise; I have clients doing back end processes in RPG III, RPG IV and even COBOL, depending on the skill set of the staff. It works for them, so it works for me. Although I have expressed doubt about the suitability of the browser to replace the 5250 emulator, I agree that your PBD solution, or the much more expensive Jacada Innovator solution, is the most powerful way of delivering existing green screens to either an emulator or a browser by replacing the EXFMT screen with an API call. You express doubt but agree it's the most powerful solution. So, what's your opinion? How do you propose to place legacy systems on the Web? Or do you question the need to do so? If you don't agree that there is a growing need for Web access to legacy systems, then we have a fundamental disagreement that really makes further debate pretty pointless. Notice however, that this is a powerful, cost effective solution for the business which doesn't add web skills to a programmer's arsenal. Assuming one actually wants to process green screens in a browser, it's the right thing to do, but let's not delude ourselves that we now have any web skills out of that. Programmers need to understand we leveraged existing RPG code to deliver screens to a new medium, and that's all. It may help the business, assuming the screens work decently in the browser, but it won't help the programmer get a different job. My only polite response to that is "bullpuckey". If you design the entire flow, from the RPG program through the servlet and onto the web via a JavaServer Page, you can indeed learn plenty of Web skills. You don't HAVE to; if you have a competent HTML designer, you don't need to do anything beyond the host. But if you choose to do so, you now have a wonderful medium for learning how to design Web screens. You can use your existing AS/400 skills to write programs that work on the AS/400, and then replace the UI with the thin client. If you use some sort of ugly screen generator to do it, or outsource it, then no, of course you won't learn anything. On the other hand, though, if you can do that yourself, you'll have learned a decent amount of HTML in the process. BTW, the revitalization architecture also allows thick clients, so if you want to learn how to write thick clients using Swing, you can do so the same way. Debug the logic on the AS/400, and then simply attach the user interface code. Yet another nice way to learn a new technology. I just finished writing the entire back end of a jobs web site, and I've never written a line of HTML or generated a line of HTML in my life. Am I ashamed? No. Nor should you be. Being able to write good business logic servers is an important skill. One of my clients is moving a standalone PC-based application currently running at hundreds of sites nationwide to a centralized AS/400, using servlets and JavaServer Pages communicating with a message-based client/server architecture. I've designed the architecture so that the client's staff can write all the servers on the AS/400 without having to know any Java whatsoever. On the other hand, if you haven't written HTML, you?re not in a really good position to comment about its efficacy. I happen to know for a fact that on an intranet, servlets and JSP have sub-second response time - pretty good as a 5250 replacement. The presentation was isolated from the business logic. Web page designers who know nothing more than HTML, Javascript, and Cascading Style Sheets created the web pages. A scripting process in Strategi, that can be performed by someone with a macro writing level of capability, mapped data buffer fields between the web pages and the AS/400 server programs. Yipes. We'd have to spend a lot longer than the time we have here to assess that particular statement. However, I'll tell you this: either the scripting language or the server is performing presentation logic. If it's in the scripting language, then the script writer must understand the business as well as the scripting language, and that means you've now translated your business logic to another language and reduced your pool of programming talent for enhancements. If it's the server (which I bet is the case), then you aren't writing general purpose servers, you're really doing exactly what revitalization does, only without the benefit of being able to run the program as a green screen application in order to debug it on the AS/400. Somewhere along the line, you have to design the presentation logic that, for example, combines order data and inventory data to display an available to promise screen. In a good client/server design, there are two distinct database servers for these two pieces of information. Then there needs to be an application server that combines responses from the two database servers to provide the information that is presented to the end user. The application server in essence builds the presentation data, but without worrying about the form that presentation will take. The UI portion of the process then applies a UI style to the data, which is where the separation of user interface and business logic really takes place. And now on to the kicker... It may help the business, assuming the screens work decently in the browser, but it won't help the programmer get a different job. To design and write API servers and accompish modularization of company business logic is a desirable achievement for both the AS/400 programmer and the company, but this will not get the programmer a different job. However, I stand by my statement that dabbling in Java or net.data to produce some isolated business solutions is neither effective for the business nor helpful enough to one's career to actually get a job on another operating system. I've got two problems with these excerpted statements. First, neither I nor anybody else has espoused "dabbling". If a business process doesn?t require Web access, then it doesn't. If your employer has no use for Web skills, then you need to learn them on your own, but with the understanding that you're probably going to have to look for a different job. Which bring me to my second point. In no way, shape or form am I advocating that someone learn a new skill in order to either jump ship or hold their employer hostage. If you truly don't like your job, then that's a different issue, but that has nothing to do with what I do for a living, which is to provide a solution that moves a company's information systems to a new technology while making their existing staff competent enough to continue the development of those systems. On the other hand, if what you want is some way to leverage your AS/400 skills onto "another operating system", then my question is "Why?" To me, that's like an Indy 500 racecar driver leveraging his skills to drive the pace car. If you don't like the AS/400 or its ultimate successors as a platform upon which to build a career, then this is probably not the best forum in the world for you. If your sole goal is find the way to squeeze the most opportune dollar out of the market, then go UNIX and ASP and VB until that particular snake oil dries up, then find a new bandwagon. If, however, your goal is to develop the best business applications on the best business platform, applications that will help propel industry into global economy of the 21st century, then learn Java, learn client/server, learn HTML and XML and figure out how to apply them to your legacy AS/400 systems. And that, Ralph, is my opinion. Joe, in not as kind and gentle a mood <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

09-16-2000, 01:47 PM

Joe Pluta wrote: I've got two problems with these excerpted statements. First, neither I nor anybody else has espoused "dabbling". If a business process doesn't require Web access, then it doesn't. Welllllllll, not exactly. Those that control what the business does and doesn't do, are often influenced by a variety of factors, including (but not limited to) the media, junior consultants from big five firms, and their nephew's neighbor's cousin. It wasn't too long ago that there was a plethora of advertisements from a variety of firms, that went so far as to say, if a business did not have a web presence, then it could no longer continue to do business. The blatency of this plus a variety of other infulencing factors, caused many firms to "dabble" whether or not there was a true business requirement or not. The perception was far greater than the reality of the situation. You don't see or hear these ads any more. At least not very often. What was discovered, was that the cost of a web presence far outstripped the benefits in so many cases. Publications such as the Wall Street Journal and Barron's document such instances frequently, along with financial facts and figures. OTOH what was also discovered was sort of a privatization of the internet. VPNs and other methods of communications were methods to speed work flow and communication among diverse companies. The ability to "tap" in to another computer sped up workflow. This appears to be the direction of business internet purpose. Bringing one's company online (to the entire world) turned out to be not the goals and objectives, but it took some "dabbling" to figure that out. Dave

Guest.Visitor

09-16-2000, 05:37 PM

The bottom line for me is, actually, the bottom line. In my world, AS/400 professionals (as skilled as they may be in biz-app development) are getting left behind. Every project that I know of today has to have some sort of "e-" in it and while AS/400 shops endlessly debate the validity of such projects amongst themselves, people like myself enter the picture to pick up the low-lying fruit. It's almost as if AS/400 pros think they're "going to the dark side" if they do less RPG and more Java. Also, I find it interesting that the assumption of my earlier post was that preliminary use of Java be used for in-house, production projects. Hardly. Ralph states that there just isn't enough time or patience in today's IT budgets and I agree. If any RPG-er is serious about Java, they'll lose the concept of Monday-Friday, 8:00-5:00 and study Java on their own time until they can produce some sort of proof-of-concept application (on their own time) to sell to their management. Anybody thinking they can cut a check for a book, seminar, or other means of instruction to become skilled in Java needs a reality check. So while we can all find examples of a genius turning to AS/400 programming, or propeller-headed know-nothings screwing up biz-apps with ASP or whatever, the question is, "Do shops today consider their RPG-skilled AS/400 personnel as valuable assets in an e-commerce project?" The answer, speaking from my recent experience, is sadly no. In somebody else's corner of the woods, it may be a different story, however. Based on this, and the fact that server-side Java (J2EE) can offer an AS/400 developer far more functionality than RPG, it's never ceases to amaze me how people will religiously cling to RPG and decry anything else as a red herring. Taking that position is to the detriment of your own career. In my region, I know of at least a half-dozen companies who've shown the AS/400 the door this year along with whatever ERP package that was on it. And I know several other shops "babysitting" their boxes until that D-day comes. The wisdom of that could be endlessly debated but the fact remains that while those AS/400 shops wondered about and speculated on and resisted "e-" projects, upper management went ahead with their agenda without them. Listen, people are either gonna choose to expand their skill set or they're not. And everybody'll have a laundry list of reasons as to what choice they made. The AS/400 platform attracts a certain type of person. A person who wants little change, stability, and performance. The assumption that anything other than RPG on an AS/400 can offer those qualities is a wrong assumption. Fervently sticking with RPG, thinking that if you learn a new technology, you'll be "cheating on your AS/400-spouse" is completely perplexing to me. So for all the Java nay-sayers in AS/400-land, keep debating. Keep putting it off. Keep wondering about it from a distance. And whatever you do, don't actually spend some of your free time studying Java instead of falling asleep on the couch in front of another Seinfeld re-run. Because I've got three kids I need to put through college.

Guest.Visitor

09-16-2000, 06:06 PM

Joe, my comments were not originally directed to you in particular, and my opinions are not responses to only what you have said here in this forum. You have good technology that competes with a very expensive Jacada solution and a well thought out architecture to replace green screens. I disagree that web access to business logic currently done in green screens is either desirable or a given. Only the market will determine that answer. I wish your PBD product well in that market. However, we do agree on an architecture approach that ties into existing code and skills. I would point out that only the AS/400 community with it's lack of a native GUI interface has this idea that a browser is the natural interface of the future for business processing. Although all platforms and environments provide for web page generation and serving, and a great emphasis exists on webifying order entry and customer relation management, other platforms which have a GUI interface only look to serving web pages as a supplement to the GUI programs where appropriate. I do not see this fixation on the browser elsewhere at all, but instead see GNOME and KDE on Linux, Motif on Unix, and Windows programs based on an ever expanding array of technologies and languages. Sure they all do web pages. Nearly all web pages are served from these systems, but nobody describes web pages as some kind of natural replacement for GUI programs. I wonder why that is, and why they don't think the way we do? You and others in the AS/400 community looking to find a natural migration from green screens to GUI are drawn to the browser as a type of ubiquitous natural emulator that nicely replaces the 5250 emulator. Unfortunately, it is nice and easy for IT. The users don't care how easy or hard it is for IT. When I see users opting for web pages over keystroke for keystroke interaction with GUI components, then I'll agree with you. Hasn't happened yet and doesn't exist. The only other thing I want to do is straighten out any misconceptions. I said that "Assuming one actually wants to process green screens in a browser, it's the right thing to do" to replace EXFMT with an API call as you do in PBD, although I think I remember reading that Jacada tried to patent that. But that's a big assumption. Nothing ambiguous about my statements. Don't know why you don't understand it. A fundamental question is what is desirable to place on the web to view and process through a browser? All of our business processing that we do in green screens? And just why would that be? I have never seen an end user opt for even a GUI'ized green screen over green screens yet, which are far more usable than a web page. This includes the GUI400 screens for JDE, the CST screens for MAPICS, and the GUI400 screens for Infinium. We got them because we thought managers would prefer the point and click, and even they find it cumbersome. It turns out that users associated GUI with the multiple window, drag and drop, drill down, everything at your fingertips design and *hard* work of a well designed and written GUI program. Didn't have a thing to do with installation and support, ease of generation, backwards compatibility with existing code, and general lack of trauma to IT. Yet those are the issues that IT are consumed with. So where is this advice that our ERP programs need to run over the web coming f rom, for the last three years and still not there by the way? As for how I think apps ought to be made available to the web, I have made my proposal in the IMHO article in July, which is a native Java GUI for the AS/400 from IBM. Much of it can be done currently with Host on Demand and Jacada Innovator, but I stressed an XML protocol to open up the AS/400 outside of the 5250 converter community to the rest of the world with a unique new kind of interface of dynamically generated GUI screens. I think the next best approach will be to use the new standard AS/400 VisualAge development environment, or ASNA Caviar, or your PBD tool, to develop thin client programs that call AS/400 programs, being careful not to fall into the VB trap of writing thick client programs with the business logic and I/O in the client. Where there exists a need to provide a professional web interface to the public or business associates and partners, then I agree that placing well designed web pages in IFS and serving them with integrated data from the AS/400 is desirable and a wonderful thing for the AS/400 shop to accomplish. However, I have found that web page design and creation for a professional presence is a serious business unto itself. The Strategi scripting that links buffered data fields to web page fields is an elegant link between AS/400 server programs and professionally developed web pages with no embedded HTML statements that link the page to a certain technology. The scripts are stored in a file in the IFS in the same directory as the web pages. I think it is a powerful, elegant alternative to CGI or servlet programming.... just a link between any group of AS/400 programs and web pages, neither one having anything hard coded about the other. I find it at least as much of denial as an RPG programmer wanting nothing to d o with anything but RPGIII to scoff at a native AS/400 web server that is light years faster than Websphere that allows us to communicate directly to web pages without CGI or Java servlet programming, and I mean sub second response. The results leverage everyone's expertise very well, not that we couldn't open up IFS and do our thing with those web creation programs... I'll leave that to the artists while I write database crunching programs. I say all this to let those reading this in the forum to know that web serving from the AS/400 can be as painless and fast as 5250 serving. It requires writing programs that work like a RCV SND dataq loop and then case out to different routines, and the code must be stateless, meaning you have to move a key around in the web page and store any data away in files so that it can be retrieved the next time the web page comes in, if necessary, so it's very different from web enabling existing green screens, but then we do want a professional web presence, don't we? And by the way, I've been programming RPG on the AS/400 for 11 years, and intend to be doing that at least another 11, despite a summer working on the client/server rewrite of BPCS Order Entry which you may remember. If that didn't turn me to Windows, nothing will. :) Regards, Ralph

Guest.Visitor

09-16-2000, 08:02 PM

BTW, I have no relationship with Advanced BusinessLink, and I've seen a lot of Lansa ads out there. I'm sure they have just as good a web serving solution. Haven't looked at it. Also, have nothing against Java servlets and JSP with Websphere, when web pages are an appropriate business solution. I got sidetracked a bit from my original point..... Ralph

Guest.Visitor

09-17-2000, 03:32 AM

Jeff Markham wrote: Based on this, and the fact that server-side Java (J2EE) can offer an AS/400 developer far more functionality than RPG, it's never ceases to amaze me how people will religiously cling to RPG and decry anything else as a red herring Can you be specific here? Dave

Guest.Visitor

09-17-2000, 05:42 AM

This might be way off topic, but has anyone dabbled in the port of COBOL/CICS apps from 370 et seq. mainframes to the 400? I still think that a majority of actual business paradigms are imbedded in that technology rather than in anything connected with the Win-Intel paradigm. One very large retailer is contemplating such a move; their business logic is entirely in COBOL and COBOL/CICS but many of their shops use small 400 to collect day-by-day, minute-by-minute stuff. I also know of one very large bank looking at the same transition. bobh

frankgw@adelphia.net

09-17-2000, 09:01 AM

To Ralph, Joe & others - I for one find this thread very interesting. Wish I could contribute more to it, but am still waiting to see which way to personally jump. That brings me to a question for both of you and anyone else qualified to comment. Where does Domino play in this picture? Here's my dilemma. There are so many competing directions for a small AS/400 shop to go and not enough time to evaluate them all. That's where sharing and debating ideas in a forum such an this one can help many of us still waiting to see which way the wind blows hardest and for a long enough time to allow us to finally take a leap of faith one way or another. Ralph, Joe & others, keep the debate going. Thanks.

nycsusan@hotmail.com

09-17-2000, 12:54 PM

Frank, I am very glad that you brought Domino into this discussion. Thanks. I look forward to the comments that the others will have. In the meantime, here are the reasons that our group chose Domino over Jacada, LANSA's New Look, SEAGULL, etc., etc., etc. And yes, we did take the time to evaluate them ALL. Requirements: Our client wants a NEW contract creation and implementation system with LOTS of change tracking, data entry validation, security limiting who can view and approve contracts during the various stages if its' life cycle, and this new system must eventually feed the data into the existing legacy COBOL batch system on the AS/400. They want to continue to use MS Word for the legal jargon and Excel spreadsheets for the rates in these contracts. And all of this is to have a "fun" GUI front end accessible via the Internet. It seems to me that most of the solutions discussed here so far are for converting existing AS/400 screens into GUI pages for the web. That's fine and dandy, but our contract system does not exist yet, it is brand spanking new. What about brand new development? We could have coded from scratch using COBOL, e-RPG, Java, LANSA, etc. In the end, Domino already had built-in functionality to handle document handling with an approval process, so we chose it as the base of our solution. It all comes back to, do what makes sense. We were crunched for time, Domino was free to us, and Domino fulfilled the primary requirement of document handling and tracking. If you just want to throw your existing screens on the web virtually "as is", then it seems to me that many options have been discussed at length already. To me, the problem is when you want to create NEW AS/400 applications and deploy them on the web. That is when your headaches really begin. In this business, it is a luxury if you can train on the job while continuing to earn the salary of an experienced programmer/analyst. Most often, you have to learn at least some of it on your own time and at your own expense. While I understand more than most the need for balance in life, I also know that extra hours for classes or home study are only temporary. They had better be, or I'll be joining some more very different forums.

J.Pluta

09-17-2000, 05:36 PM

I'm becoming an ardent supporter of intranets for businesses. It seems such a great way to give everyone access to shared data. Giving browser access to AS/400 applications is just one more component of that process. 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

09-17-2000, 05:39 PM

"So for all the Java nay-sayers in AS/400-land, keep debating. Keep putting it off. Keep wondering about it from a distance. And whatever you do, don't actually spend some of your free time studying Java instead of falling asleep on the couch in front of another Seinfeld re-run. Because I've got three kids I need to put through college." Well put, Jeff... I appreciate it <laughing>. That's exactly what I needed to hear to shut my butt up and get back to work. It's been a rough week, and I was getting a little frayed around the edges, but your perspective is exactly correct. Back to work. <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

09-17-2000, 05:52 PM

I'm just going to respond to one thing here, because I have a raft of work to do tonight (and indeed for the rest of the year). "It turns out that users associated GUI with the multiple window, drag and drop, drill down, everything at your fingertips design and *hard* work of a well designed and written GUI program." Absolutely, Ralph. That's why the PBD approach (which, by the way, is now officially the eDeployment approach, to be showcased at COMMON) in no way tries to present a GUI screen to the user. It is simply a browser-based interface to an existing application, but with the idea that the browser presence merges seamlessly with the rest of the website. eDeployment, Inc., provides all the components needed for that, from security and web presence to multimedia to application revitalization. BTW, I think Jacada would have a difficult time trying to patent the revitalization technique since I've already put it in the public domain. They say they've been working on theirs for years, but I still can't understand why an entire team of Java people took years to put together what I did by myself in my spare time in about a year, and then theirs suddenly came out about three months after mine was published on the Internet on Java400.net. But then, coincidences occur. 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

09-17-2000, 05:58 PM

Writing true client/server applications is a completely different animal than writing server/client revitalization applications. Host-centric applications that have control of the screen are fundamentally different than stateless applications run from detached workstations. If you want to write a client/server application from the ground up, you have a much different set of goals than any you've probably run into in your typical AS/400 development environment. I know of very few people who have even attempted to build a true client/server application architecture on the AS/400, and most of these attempts failed miserably. The best was a trading system I developed for Shatkin and Associates way back when on the S/38 of all platforms. It allowed realtime processing of trades so that the traders could get their balance at the end of the day in time for overnight deposit in a bank account (those fractions of a percent of interest added up very quickly). On the other hand, from what I understand, Domino is wonderful for DOCUMENT PROCESSING. That's the domain of what is often called "workflow management", when non-relational data is passed from work center to work center, triggering various events along the way. The problem many people run into is then trying to use Domino as a relational data processing environment, treating each database record as a document, at which point the engine just curls up and dies. My brother is the Domino expert in the family, so I can't be very helpful here, except to say that if you manage to separate the document processing and transactional database processing aspects and implement only the document processing via Domino, it seems to work very well and has a very strong Web integration aspect. 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

09-18-2000, 01:11 AM

I've started using Domino for a few new applications that don't demand much integration with the existing DB2 database. The speed with which you can develop forms and views is gob-smacking. The biggest danger is that I'm beginning to look upon our RPG interactive programs with disgust. Having said that though, Domino has several severe limitations. Every 'record' in a Domino data-base is self defining, meaning it takes up an awful lot of space compared to a relational data-base, and lacks any predictable geometry that allows fast access. So it doesn't scale at all well. Another down-side is that Domino doesn't interact well with the host 400. A bit of SQL and that's about it. Although Domino is using the 400 as a repository for its data-bases and forms/views/programs, all those other 400 resources that the RPG programmer takes for granted might as well not be there. You can call Java classes, and can therefore access the 400 via the Toolbox, but these Java classes don't appear to be able to access the interactive elements of a form - meaning they're not much good for editing a form (I may be wrong in this, and hope I am).

Guest.Visitor

09-18-2000, 03:07 AM

Hi Susan, After reviewing Domino R5 features to see where they are now, I see they have realtime access to DB2/400. This is a real advancement that was a showstopper earlier in my opinion. That and the fact that it runs on the AS/400 now instead of the Intel card. I hope the document storage project worked out well, but I thought I'd throw in my two bits on new development in general, as you commented. I considered Notes to have the butt ugliest interface I had ever seen... until I saw the subset that Domino could display. A couple of years ago Notes had the cachet that Oracle does now, that was a real bandwagon to jump on. Oracle has usurped it and I think Notes programming will never again have the prestige it had. However, I did see that Domino Designer was nearly as good as Delphi and Visual C++ in its connectivity options and incorporation of other development environments. An interesting point is that I saw where Lotus says the merging of Domino and Notes will be done by programming in Javascript. Note that although Javascript has the word Java in it, it has nothing to do with Java. Talk about jumping on a bandwagon. Speaking of Designer, I saw the ultimate display of the difference between Windows programs and web pages in a screen shot of Domino Designer being used. In the Notes.net technical paper Domino Designer Technical Overview, a screen shot shows a Notes web page being designed. The difference between the Designer windows program and the web page being created with it is like comparing a child's crayon drawing to a Rembrandt. On the other hand, I do understand we can't develop suites of Windows programs instead of green screens... or can we? I guess we could buy into the JDE OneWorld development environment. The notion that is frequently floated of the Intranet/Internet requiring a browser to access data is very misleading. Every program that communicates over TCP/IP communicates over the Internet just as well as a browser. Client Access, Delphi/400, Visual RPG, ASNA, and every other product communicates with an AS/400 from anywhere on the Internet once the TCP/IP stack is fired up and connected to an ISP. The issues are cross platform and deployment, and I believe more powerful solutions than web pages are available through Java products that also address those issues. For new development in general, I think Java 5250 emulators should be considered for processing green screens on desktops without a 5250 emulator. I had a requirement a while back to bring HR in across a WAN to process data. They were various business acquisitions that had never seen a green screen, and there was a directive not to traumatize them with one. I had the opportunity to have some input into the feature set of the BusinessLink Strategi 5250 emulator, available as a Java applet. Not only does it recognize subfiles, but you can click on page up/ page down, the option to take, and then double click on the subfile row for it to take action. Write programs with F4 pop up select windows for every field with valid entries in some file, and an end user can process just as much of the program with a mouse as in a Windows program. The pop up windows can be dragged around to unhide portions of the screen like in Windows. Other Java emulators are Host On Demand, Jacada, and Seagull AFAIK. Of course, these Java emulators are just displaying green screens, so there is no change to current development methods. They work best on new screens that are laid out so that GUI'ization works well. Those Java emulators works through every browser and can be considered with the same criteria as we would consider web pages, but for heavier duty processing that require more than the Java emulator can display, robust Windows solutions should be considered unless we truly have heavy duty end users on different operating systems besides Windows, which is unusual. Where applications exist that require high data density and would benefit from enhancements with GUI components, I recommend Jacada or Seagull to pull green screen data into a Window program that is truly a thin client but interoperates with other Windows programs such as a spreadsheet or a word processor. We can design and build very potent Windows programs by just installing the Windows emulator and continuing to write green screens. The fact that the data is written to a green screen doesn't make the program bad, the nature of RPG just led to badly designed programs. New development can be done that takes full advantage of modularization and good interface design and the output data that is currently sent to a green screen could be sent as a buffer to a dataq for that matter. If every good development technique of ILE RPG is used, the programs will be just as well done as if the output were intended for some other interface. Lastly, for document integration, I would recommend Magellan, a top to bottom document management product. The tight connection that Magellan provides between AS/400 business data and stored documents allows the launching of a document into the Spyview viewer or a web page by pressing a function key on the 5250 screen. At that point, you have interoperability between Spyview and Windows programs to work with the document data. Again, no change to current development methods and languages, and the unique power of the AS/400 is fully utilized. The comments you made are right on, Susan. Hope this helps someone in considering new development directions but of course a working Domino system is just as good. Regards, Ralph

Guest.Visitor

09-18-2000, 03:21 AM

Hi Joe, You have done us all a big favor by bringing your solution out and hopefully preventing Jacada from attempting to patent methods for working with multiple interfaces inside the AS/400. They should be truly ashamed and I would hope potential customers would consider eDeployment Inc. and all the open sourced research that you have made available versus Jacada's bring you to your knees pricing and attempts to hijack the internals of the AS/400. Regards, Ralph

Guest.Visitor

09-18-2000, 05:16 AM

Susan Behrens wrote: Domino was free to us Sue, How did you manage this one? Dave

Guest.Visitor

09-18-2000, 06:12 AM

ladies and gentlemen, I have read this thread with great interest. However, there is one thing that is not discussed here. I would very much appreciate your input on the following : So far, all I have read focussed on application-development. Now I myself am an AS/400-system-consultant. I once was a full-time programmer on the S/38 and the AS/400 and I have knowledge of RPG, Cobol, UIM and CL. Especially UIM and CL, because I have written system-software for years and years(backup and recovery, attentionkey-systems, FileTransfer-software, etcetera). It suffices to say that I am somewhat of an AS/400 'general expert' ;-). In spite of all these activities, I no longer have the in-depth programming-knowledge you all have, because my projects over the last decade or so also involved performance-tuning, security-issues, etcetera etcetera. Real system-engineering jobs. Because the times they are a'changing, I can not pretend to be a full-blown programmer anymore. This is good, because I'd Rather Not Be A Programmer, especially not of the 'Old School'. So here comes my question : In this thread I have found lots of advice, for or against education regarding new techniques, but I could not find 'One bit of Info' about what would be advisable for me to do. I mean, what would be the best direction to go as a system-engineer/consultant ? Learn Linux ? For you information : I am now testing/playing with Linux. I have also designed straightforward websites for small companies so I do possess HTML-knowledge. However, the lack of a standard database-system on PC-platforms gives me the creeps ! I am used to a built-in database like DB2/400. So for instance : What is the best database-system for my PC(because that is what I will have to learn the new skills on). Which is the way to go ? Network-specialist ? AS/400-consultant/engineer ? Web-designer ? Where to go, what to do...? And what's more : where does one get the information in a useable form ? Thanks, Rob.

dchristie

09-18-2000, 06:23 AM

A good book to read (for those who have time for such an old fashion pastime) is 'Business @ the speed of thought' by Bill Gates. Of course the book leans towards Windows but the business solutions are interesting. My opinion on all of this is that there is a place for all. From the DOS entry panels at my local video store, the mechanics green screen work order entry panels, to upper management consolidated data panels on the Web.

nycsusan@hotmail.com

09-18-2000, 07:04 AM

David, How did we get Domino free? Did you think it was due to my vivacious personality? :-) Seriously, Domino is included in the contractual agreement between my employer and IBM. Yes, my employer is a major player in the Information Solutions industry. Intrigued? :-) Sue B.

nycsusan@hotmail.com

09-18-2000, 07:55 AM

Rob, What do you WANT to do? What is your goal(s)? Do you want to be happy in what you do? Then only you and those that know you best can help you. Do you want job security by getting the "hot" skills? Then search the classified ads where you live and see what skills are in demand. In my area, any skill having to do with the Internet will guarantee employment. If you want to program, Java is hot, and it doesn't tie you to any one platform. But if you are not interested learning in Java or in programming in general there are other options. Graphics designers are in demand too, not only for web pages but for other multimedia work. I am working towards that myself. So, Rob, what are your goals, both short term and long term?

Guest.Visitor

09-18-2000, 08:07 AM

Hmmmmmmmmmmmm. I'm thinking that Domino may be included your agreement, but that it isn't free. Just my innate cynicism rising to the forefront. Dave

nycsusan@hotmail.com

09-18-2000, 08:36 AM

What?!?! You don't believe that it's my vivacious personality that gets us free software?!?! David, You ARE such a New Yorker!!! ;-) BTW, so am I (Queens & Brooklyn). Nothing in life is truly free, we all realize that. Think about it. If we use Domino or any other IBM product in our solutions to our clients, you bet your bippy that IBM benefits from that. You scratch my back and I'll scratch yours, so to speak. I think my employer pays a (big?) flat fee in exchange for this "free" software, but I am not privy to those negotiations. All I know is it's free to my boss, whereas Jacada, LANSA, etc. are not, so it's less hassle. In this case, however, Domino did advertise the workflow management feature which is a primary requirement of our project, so it was the logical choice.

Guest.Visitor

09-18-2000, 08:41 AM

Bob, Cobol/CICS on the AS/400 works quite well for porting applications from the mainframe. I worked on one such project. There's a bunch of work to do, but it works quite nice. HTH

nycsusan@hotmail.com

09-18-2000, 08:54 AM

Ralph: "I hope the document storage project worked out well, but I thought I'd throw in my two bits on new development in general, as you commented." Thanks Ralph. I have printed off your comments to think about (and perhaps even respond to) later. But just so you know, our project is a big hairy mess that is STILL in development. I WISH it were done. Now that I know who the Domino experts are, I'm gonna come knockin' !!! :-) Sue.

Guest.Visitor

09-18-2000, 09:38 AM

Susan, Thank you for the swift response. The problem is(IMHO) that after 18 years of S/38 and AS/400 work one tends to become very experienced at what one does. This of course is reflected in the business you run(I have a one man-company), and also in the amount of money you make from IT. So I would think it is virtually impossible to switch to a completely new platform and at the same time make sure your business is safe. I cannot imagine that a client with a PC-platform would pay me the rate that I get on the AS/400. Not without a lot of experience. So this is sort of a Catch-22 situation. So what I would want to do is get to know the new technology in my own time and then apply it to hybrid-situations where the AS/400 coexists with let's say a windows- or a UNIX-platform. Later on I can then move more in that direction. However : there is WAY too much new technology to get to know it all. I therefor have to start somewhere. So to answer your question about what I want : I am a consultant and I would like to stay a consultant. What I MUST do is stay in the business. In the end I want to do on any other platform what I can do right now on the AS/400. I do not think that I can go 180 degrees, I will have to learn those new skills gradually. So the question for me is not so much 'what do I want', it's more a question of 'Where do I start and how can I apply my AS/400-knowledge to this new direction most efficiently' ? That and : 'Will I be able to make a living' ? A question my wife would like the answer to as well, for obvious reasons... So yes, I could become a webdesigner, quite a nice job. But to put that in perspective : How much would I be able to make ? Would I be able to run my company the same way ? Might it be better if I focussed on network-technology ? Would learning how to program JAVA also teach me the inner working of the PC-industry. Where is the most efficient place to start ? Right now I have taken a bite from all the cookies, what I want is to bake them. Do I learn how to make dough first, or do I just buy that and focus on the baking ? ;-) Should I wait for the moment the first cookies roll off the productionline and then start to focus on the dough ? Perhaps some of you already made this switch. if so I would like to hear about your experiences. O.K. shoot ! Rob.

nycsusan@hotmail.com

09-18-2000, 10:01 AM

Rob, I am in the same boat, but with a little less experience. I have almost 11 years on the AS/400. I too am ready for a change, and I too, would prefer not to take a pay cut. Like you, I am paid for my experience. If I take a position such as a graphics designer, I am no longer experienced and probably will have to take a pay cut. However, if I can find a place that uses the AS/400 as a web server, and part of my new dream job is programming in Java, XML, HTML, JavaScript, etc., then my experience IS relevant and (I believe) I should not be expected to take a pay cut, at least not a BIG one. If you are a one man company, and you want to branch out into graphics, for example, then have you considered hiring an employee who is experienced in that area? If web design interests you, you could do that in addition to your "day job" for a while. I am taking classes at night, and networking with my graphic artist classmates and teachers. My goal is to be spending at least 20 hours per week on web site design or even pure graphics movies by the New Year. I will let you know how my "cookies" have turned out! :-) Rob, Here are some ideas. Take some classes in your areas of interest. Make sure graphics or UNIX or the XYZ programming language really is of interest to you. Make contact with your teachers, who in theory have contacts in the industry. The bigger the departure from what you are doing now, the more likley it is you will either have to work 2 jobs or take a pay cut. Or, since you are self-employed, is it possible to hire a contractor so that YOU can learn from him/her? Good luck, Rob.

Guest.Visitor

09-18-2000, 10:06 AM

Sue Behrens wrote: I think my employer pays a (big?) flat fee in exchange for this "free" software That seems more reasonable. Dave

Guest.Visitor

09-18-2000, 10:48 AM

You mention LANSA. Is it worthwhile learning LANSA or would time be better spent learning something else (C++, JAVA, ILE)?

nycsusan@hotmail.com

09-18-2000, 11:06 AM

"Is it worthwhile learning LANSA or would time be better spent learning something else (C++, JAVA, ILE)?" George, it depends. By worthwhile do you really mean "profitable" as in, will it qualify me for my dream job making lots of dough? I see it as playing the odds. Odds are, IMO, that you are more likely to find a job requiring Java than either LANSA or C++. Personally, I really liked developing in LANSA a LOT. I used it for about 5 years almost exclusively. Once you are past the learning curve, it really does increase productivity. If I had the choice, I'd write all of my code in LANSA. On the other hand, I can tell you that having LANSA on my resume has mananged to elicit the question "Lansa? What IS Lansa?" in almost every job interview. Only once did my LANSA skills get me a serious job offer. The main problem is that LANSA is that it is expensive and I just don't see that many shops that using it, yet. The shops that do use it most often list the LANSA skill as a nice-to-have but not a mandatory skill, whereas most of the Java jobs I see do want some experience. For those reasons, I would recommend learning Java before LANSA. You will qualify yourself for more jobs that way. However, if you live in the Chicago area (where LANSA USA is based) then LANSA might be an attractive option for you.

Guest.Visitor

09-18-2000, 11:11 AM

Hi Rob, My recommendation for you is that you prepare yourself to continue being an AS/400 system expert by becoming an expert in Linux. This requires that you learn C well, as well as Linux/Unix administration. The reason is that IBM has stated that it will run Linux on the AS/400. This is my interpretation of how it would work from IBM info. I believe it will be in an LPAR and that they will duplicate the AIX Unix process in the Linux LPAR of "preparing" Unix programs to run in the AS/400 PASE environment. Whether one wants to consider PASE as part of OS/400 or something else, PASE executables must be compiled from source that complies with certain limitations to be able to be hosted as an interoperable AS/400 object. Linux running in an LPAR would be the same as running Linux in a partition on your PC hard drive, and therefore runs as it would anywhere, as its own operating system running any program the way it would elsewhere. I assume that the Linux LPAR would have access to the DB2/400 database files in realtime. As far as I know, this is currently being done with Domino Notes. Notes had a separate database partition on the AS/400 and was synchronized periodically, if configured to do so, with your designated DB2 files. As far as I know, the periodic synchronization has been replaced with a real time synchronization, unless the Notes database has been ported to DB2. With blob support in DB2 now, maybe it has. The requirement to master Linux implies a requirement to master the C language. Linux is an open source system written in C, and nearly every Linux specific open source utility and program is written in C. Of course, there are dozens of open source Java programs that run on Linux as well as elsewhere, but they have nothing to do with becoming an expert Linux systems person. In addition, the visual interface that IBM and others will use is GNOME, a windows like interface. IBM failed with OS/2, but they will not rest till they no longer have to pay homage as well as major bucks to Redmond. The GNOME APIs are APIs with a C interface, and regardless of how convenient it is to think "Java rules, I'll learn Java and program anywhere", the reality is that becoming a Linux expert is working specifically with all that open source C code of Linux, GNOME, and myriad Unix utilities. Anyone capable of learning one is capable of learning the other, and Java was created with C progamming migration in mind, but they are very different, C being based on pointers and Java with it's object orientation. Again, I have no commercial experience in C, Java, or Linux, and I couldn't go out and get a job in those technologies, but this will be a requirement to continue being an AS/400 systems expert as you are now. An RPG or COBOL applications programmer would want to focus on Java. However, I do not see the requirement of knowing Java for the AS/400 as imminent as the need to support Linux will be for a systems person such as yourself. I have seen no Java specific development jobs for the AS/400, but of course many that say that Java is a direction. The cost justification for developing in Java hasn't been successful yet. The theory that Java OO development will create an infrastructure that makes future programming more efficient and less costly remains a theory, with IBM pouring billions into the San Francisco infrastructure to bring theory to life. If they succeed and the business object framework is melded into VisualAge for Java at a reasonable cost, perhaps the dawn of a new programming age will emerge and those that have worked to learn Java as well as businesses using it will benefit. In the meantime, attempting to make a business case for developing in Java is difficult, or everybody that owns an AS/400 is stupid, whichever you prefer. Regards, Ralph

nycsusan@hotmail.com

09-18-2000, 01:18 PM

JVT, Have you tried to integrate Domino with MS products such as Word and Excel? Also, have you tried to do real time searches on AS/400 files via Domino? What I mean is ... we want to populate drop-down boxes in Domino with data from AS/400 files, or, send the entered value to the 400 to verify that it is acceptable. We are trying to not to duplicate files in Domino that are already on the 400. We need to do real time. Have you tried it? TIA, Sue B.

Guest.Visitor

09-18-2000, 03:51 PM

Sue B. wrote: Have you tried to integrate Domino with MS products such as Word and Excel? Not yet. Only attached them to rich text fields. Also, have you tried to do real time searches on AS/400 files via Domino? What I mean is ... we want to populate drop-down boxes in Domino with data from AS/400 files, or, send the entered value to the 400 to verify that it is acceptable. We are trying to not to duplicate files in Domino that are already on the 400. We need to do real time. Have you tried it? I'm trying to access our production 400 real-time as well, so I don't have to do any file duplication. As for populating drop-down boxes, not much luck. According to the Lotus Help, the @DBColumn and @DBCommand commands can access relational data-bases via ODBC, but I've never been able to get it to work. I keep getting '<Data Application Layer Errors>'. I notice this question is posed a lot on the Notes.net forum, and never gets answered. If you are serving HTML rather than Notes clients though, there's a good news/bad news scenario. The good news is that Domino runs servlets, and servlets can get at data queues, data areas, RPG programs, service programs and record-level access. Data queues are the real bonus, in that the response time is very fast. You can have an RPG program waiting on a data queue, and firing off an answer to a requesting servlet whenever an inbound message is sent to it. The RPG program only needs to be started up once, and shut down only when you want to change it. The bad news is you have to brush up on your Java, and code the servlet to generate the HTML that gets written to the browser. So you have all the freedom in the world to edit a form and high-light errors, position the cursor by writing a JavaScript focus statement in your HTML, load up all your drop-down boxes from whatever 400 file you want, but you get this ugly big job of hand-coding each form in HTML. All the productivity advantages of designing forms interactively in Domino are lost. In a perfect world, a Domino form could run a Java class interactively on the 400, passing parameters, or maybe even LotusScript on the server with access to Data queues...

Guest.Visitor

09-19-2000, 03:55 AM

Susan, Ralph, It's nice to hear some confirmation of my ideas, I had to determine my path by keeping up with the official webmagazines, IBM-sites, gossip, rumours, etcetera. I have indeed installed Linux on my PC now, and I am focussing on C++/JAVA somewhat. The main question is still : 'Will Linux on the AS/400 be a success ?'. It is the reason that I also put C++/JAVA on my list, it's a bit more platform-independent. One of the major problems in determining where to go, is the fact that about 4 out of 5 'new developments' turn out to be hypes to some degree. So I focus on Linux because I can always use the UNIX-experience that it will give me. Same with JAVA, OOP is most definitely a good idea(IBM has been using the method for years when building OS/400 ;-)). BTW : I know that IBM tries to supply the AS/400-community with training-classes about the new developments to come in the next generation AS/400/500/600 whatever. I just don't think they are doing enough. After all : we DID make the AS/400 what it is now. So IBM owes it to us to make more, better, and cheaper, transitional training-classes. I mean, I have seen the Linux-introduction on their site and it is so basic that you don't learn shit from it if you have ever read a book on Linux. I want a book that tells me how things are done in Linux compared to OS/400. What do you do when you want a WRKACTJOB ? That would teach me a lot. What is the best way to maintain your security (-wxr-x versus *USE for instance). In addition to that, I think IBM should take a clear point of view(for all to hear) about support of the AS/400. Will it be there, and still be improved on, in 3 years ? 5 years ? 10 years ? Nobody knows, that's why this forum is frequently buzzing with rumours(no more RPG-support, the AS/600 is coming, etcetera). Rob.

J.Pluta

09-19-2000, 08:34 PM

The notion that is frequently floated of the Intranet/Internet requiring a browser to access data is very misleading. Every program that communicates over TCP/IP communicates over the Internet just as well as a browser. While I'm not sure who you've heard say that browsers are required, Ralph (I know I haven't), there is a fundamental advantage of the browser approach over all the other solutions: you don't need additional software. Any thick client solution (even the so-called "thin clients" of JWalk, et al) requires that you have two pieces of software, one on your client and one on your host, and that these two pieces are tightly bound (a change in one necessitates a change in the other). The problem here, of course, is that this requires software distribution in order to keep the client current. If you've ever developed and successfully deployed a true client/server application like the ones we did at SSA in the early 90's, you know what I'm talking about, and you know that keeping the client and server in sync is a Herculean task. It's even more daunting when your client is any anonymous user over the Internet. A pure HTML approach requires no such binding, and so is a true thin-client approach (the definition of thin-client being that the software required on the client is simply that which is normally part of the base OS and does not require updates as the host changes). For new development in general, I think Java 5250 emulators should be considered for processing green screens on desktops without a 5250 emulator. For new development, I personally advocate client/server technology from the beginning. A good, message-based client/server architecture makes use of the strengths of both the AS/400 and the client. Designed correctly, you can use a browser, a thick client or a green screen without changing a single line of the business logic. And this is why I don't like emulators. Because you do a lot of work developing the GUI, without doing a single thing to allow you to move to the client/server environment. By using an approach which completely removes the 5250 data stream, you have a clean move to the next stage of client/server processing - WITHOUT HAVING TO REDESIGN YOUR GUI. The messages you use to communicate between the UI server and the application client (which is the term used for a revitalized legacy program) can later be used to communicate with a pure application controller, which in turn talks to true business logic servers. This way, you can gradually re-engineer your business logic without having to do any redevelopment of the GUI. You can't do this with a 5250 emulation approach. Where applications exist that require high data density and would benefit from enhancements with GUI components, I recommend Jacada or Seagull to pull green screen data into a Window program that is truly a thin client but interoperates with other Windows programs such as a spreadsheet or a word processor. And IMHO, this is the worst of all possible worlds. It is not a thin client in any form; it is a bound client (requiring additional software on the client that changes as the host program changes) AND it depends on the 5250 interface. I find this solution only applicable in orphaned applications - legacy applications that either have no source, are not going to be enhanced, or are destined to be replaced in a short time frame. The fact that the data is written to a green screen doesn't make the program bad, the nature of RPG just led to badly designed programs. New development can be done that takes full advantage of modularization and good interface design and the output data that is currently sent to a green screen could be sent as a buffer to a dataq for that matter. I love it when I vehemently disagree with one sentence then just as strongly agree with the next. RPG programs are not poorly designed; they are designed to be monolithic. The fact that monolithic programs are no longer a good solution simply means that we didn't see far enough ahead - sort of like using two digits for the year. The blockmode user interface of the green screen application is and will continue to be an effective way of entering large amounts of data; a majority of power data entry personnel don't like graphical screens, unless particular care is taken to make them function JUST LIKE THE GREEN SCREENS THEY ARE "ENHANCING". This is why the HTML interface is perfectly acceptable for those applications. On the other hand, designing a program to communicate via data queue is exactly the right approach - and it can be applied to existing programs. As you know, this is exactly what revitalization does. To design your programs from the ground up to use a data queue approach would make the user interface choices just as flexible as revitalization does for existing programs. <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

09-19-2000, 11:04 PM

You make a good case for your triple option revitalization approach, Joe, and as I agree with you in principle you'll have the last word on this. I am neither happy with web pages nor Java emulators nor bound clients, which is why I proposed a native AS/400 visual interface in the first place that dynamically generates Java Swing screens based on an XML datastream similar in concept to the 5250 approach. This obviously isn't going to come from IBM as they have sunk billions into buying Notes and trying to make Domino the interface of the future. Perhaps it can be a fourth option in PBD. Hopefully without repeating myself, my experience has been that end users want jam packed green screens with lots of data and options, and would prefer that same data, even more, in the multiple window, drill down, look things up, drag and drop, and multiple activities of a real GUI interface, that being Windows or XWindows, not just multiple fonts with little pictures and the drop downs of a web page. Web pages, given their space constraints, have so far been designed as dumbed down with multiple page sequences to perform functions in a way that end users have not accepted. SAP caught a lot of flack over this on order entry, I mean major flack, and succumbed to the outpouring with a promise to redesign the process. I will remain a skeptic until I see your PBD handle complex green screen processes and will have no problem accepting that it takes 1024x768 to do it if the market accepts that. Perhaps the same tabbed approach that bound clients such as Seagull use to access all the data required to perform c omplex work will be in the web pages as well as the Java 2 clients. If so, the same technique used to deal with the larger footprint of GUI'ized data will do the job in the browser and browser applet thin clients. One last note. I have used the bound client terminology for Windows emulators as you prefer but am amused at the usurping of the term thin client to mean web pages. This of course is not true but it makes browser advocates happy. You are by no means the first, Joe. I have encountered this code word for web pages for the last few years. I'll elaborate for the others. Clients were programs written to handle interfacing with the end user. Although the computer science theory mumbo jumbo of this stuff goes back in time along with CASE, AI, OO, and all the other stuff that will theoretically make software development a science instead of a black art, the reality is that when they came into vogue they were Windows programs. The Windows programmers wrote the programs as they had always done, performing all logic and database I/O in the Windows programs. The server ended up just being a database server, and the database was accessed with ODBC and other native database drivers rather than from a database on the local PC hard drive. This led to the nightmare that Joe described of attempting to synchronize client and server logic and database design. There is probably nobody in this forum that hasn't seen a VB project that was killed before it killed us. These logic laden programs were termed thick clients. The less business logic and awareness of the data source, the thinner the client. The web pages of a browser have joined the emulator as ultimate thin clients in that they have no logic or data source awareness. They are both thin, but the resolution and protocol differentiate them. Visual programs that make calls to a server to perform processing and database I/O are also thin, but thicker than a browser in that API names and parms are coded and data is arranged within GUI components for processing. The nightmare was really the distributed business logic. This same process of mapping data to components still takes place but everybody but me advocates that it take place as a program run by the web server. Windows programs that have little else but screen layouts and API calls seldom need updating, but it's trivial to develop systems that have a startup that checks for updates and FTP the newest version of the program before it's started. When programs were large and contained logic that changed daily, this was a synchronization nightmare. When it's a so called bound client such as Seagull that only pulls down updated or new templates, it's apparently bad because something is actually stored on the PC. Apparently caching applets will not be used for the same reason. You have the last word, Joe. We can't go wrong with green screens or web pages or Java Swing, all from the same code. However, since green screens are supported, let's at least acknowledge that Java applet emulators are a better way to handle them for remote access. Otherwise we start tiptoeing back to that little thing about browsers being required for remote access. Ralph

Guest.Visitor

09-20-2000, 12:54 AM

Before Joe can get in the last word, I have thick versus bound versus thin versus vanishingly small running through my mind and I realized, I've forgotten the point, the end users don't care a whit about what's convenient and theoretically elegant for IT. Millions of Windows programmers are writing code as we speak with no such compunction about creating complex feature laden thick client programs. And they are eating our lunch. NT sells not because of any comparisons of servers but because end users are buying Windows programs, and they are buying them precisely because they are thick clients. I remain convinced that the entire array of arguments of elegance underpinning the replacement of green screens with web pages will become meaningless as Windows and Oracle Java programmers forget to listen as they write powerful GUI solutions. The end users are and increasingly will buy these programs from companies that unabashedly make powerful client programs. Every argument of internal IT elegance is made mute by people who just don't care how elegantly you created a thin client. The statements of the IT industry that the web page interface is inevitable does not jibe with reality. If we want to survive, we'd better listen to those who use and purchase the software. What is convenient for occasional access from over the Internet has nothing to do with business software. Fine, Joe shoots the data out to Java Swing programs that we can write too, so he's covered. This isn't about Joe, the question was what do we replace green screens with? How do we write programs now? In what language, and to what visual interface? The sad truth is that millions of programmers have no such questions, they are pumping out Windows solutions that give people more power and flexibility, and that is what the people are buying instead of AS/400's. And they know what a Windows program is supposed to look like and how it should be developed. We're going to lose unless we start writing Windows programs or we develop one heck of a standard for AS/400 Java Swing programs and start writing them. Because thick will beat thin. The end users say so. Ralph

Guest.Visitor

09-20-2000, 03:29 AM

Joe Pluta wrote: The fact that monolithic programs are no longer a good solution Before I get on my high horse, Joe, I'd like a better explanation of this one. Dave

Guest.Visitor

09-20-2000, 07:40 AM

Thanks for your input. I'm in the Detroit area and I was thinking along the lines of profitable and marketable. Which new skill set would bring the most money so that I would not have to take a big pay cut and what skill set is in the most demand, so that I can easily find a job. I guess I was trying to avoid spending money on learning a new skill set that turns out to be just a passing fad. I hear that some companies provide free training in the latest and greatest technology to their employees if it is job related, but the company I am with does not.

nycsusan@hotmail.com

09-20-2000, 09:38 AM

George, Last night, I joined a Java Users group here in Dallas, and the topic of the value of getting Java certified was discussed. Here in Dallas, if you are certifed and have just a couple of years of experience, you can make well into the 6 figure salary range, and there are jobs out the wazoo. If that's not the case in Detroit, I'd move if I were you!! :-) Perhaps you could look into a Java Users group in your area and see what they have to say. Here in Dallas, we are very organized. There's even a free 12 week class to prepare for the Java programmer cert. exam. Our motto and our goal is "Become a Java Certified Programmer By Christmas!". There were at least 150 people at last night's meeting. Good luck.

Guest.Visitor

09-20-2000, 06:05 PM

Because you live in the Twilight Zone. It is Sept. 20th here, and the world only has a 24 hr difference from one end to the other, so if you are in the 23rd, what are the lottery numbers for the 21st? ==Scott==

J.Pluta

09-20-2000, 06:47 PM

I have used the bound client terminology for Windows emulators as you prefer but am amused at the usurping of the term thin client to mean web pages. <chuckle> I am offended by the term "usurp", sirrah! I far prefer to call it "redefinition", a la Microsoft. <grin> The truth is that the old definition of thin and thick client does not take into account the "ultra-thin" client of the browser interface, and since the consensus seems to be to brand browser as "thin client", I have instead rearranged the terms as follows: Thin client: No binding between client and server (i.e., browser) Thick client: A bound client, but with no business logic (screen scrape or true client/server) Remote database: A client with business logic, using the host only as a database server The VB horrors you alluded to now fall into the last category of remote database, and while I teach the technique in my classes because it is easier to debug than servlets, I also explain to my students that the architecture should never be used for production programming, since it destroys any semblance of database integrity. And the truth is, with Java it is very easy to design the application objects to run on the workstation, then simply migrate them to the servlet once they've been thoroughly debugged. I'm actually moving a class from remote database (which I taught them today) to client/server, which I'll be teaching them tomorrow. However, since green screens are supported, let's at least acknowledge that Java applet emulators are a better way to handle them for remote access. I would if I believed it, but I don't. Green screens are appropriate and indeed required for certain places where dumb tubes are better answers than PCs, primarily in hazardous environments such as shop floors. In that case, replacing a dumb tube with a Java applet emulator is wrong for obvious reasons. And for any other use, Java applet emulators are a poor use of bandwidth and a dead-end technology that provides no impetus for redesigning monolithic legacy systems into message-based client/server applications. But hey, the market will tell us before long what they want. SSA's OS/2-based client/server architecture was way ahead of anything else for many years, but the clients sort of shrugged their shoulders and said, "So what?" Until the end users make themselves heard, we can debate until our heads fall off, so we might as well agree to disagree on this particular point. <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 Toolki

J.Pluta

09-20-2000, 06:58 PM

Joe Pluta wrote: The fact that monolithic programs are no longer a good solution. David Abramowitz wrote: Before I get on my high horse, Joe, I'd like a better explanation of this one. ------- <laughing> David, I was defending RPG, not slamming it! Well-written monolithic programs are perfectly serviceable provided you don't want to change the user interface. But a monolithic program (one that combines business logic and user interface) is very difficult to redeploy without a kludgy 5250-emulation technique. When someone comes to me asking how to design a new system, I absolutely tell them to write client/server, even if client and server reside on the same box. It makes sense much more sense from several different angles: UI flexibility, application configurabillity, testing, debugging and maintenance. In my mind, there is a certain level of complexity above which all applications should be designed as client/server. The question, of course, is exaclty where that threshhold lies, and that still isn't an easily answered question. <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 Toolki

daly.michael@verizon.net

09-21-2000, 01:33 PM

Susan, Would you please send me some info about this User's Group? Thanks. MichaelD michael.daly@freshpoint.com

frankgw@adelphia.net

09-21-2000, 05:24 PM

Then there is Joe Hertvik's October 2000 Showcase article titled "IBM's $1 Billion (with a "B") WebSphere Bet". And that's just this year! The article goes on the say that IBM plans to grow that investment by double digits next year. Hmmm - A billion here, a billion there, maybe this technology should interest us. Here's an article quote. "With this campaign, IBM is attempting to attract 5 million new developers to the WebSphere software platform". That's right. 5 million (with a "M") new developers. Should that include me? Ralph, Joe and others - What do you think?

nycsusan@hotmail.com

09-21-2000, 06:43 PM

Michael, I just sent you an e-mail. In case you don't receive it for whatever reason, the website has lots of info: http://www.javamug.org/ They have a Tuesday night "Become a Java Certified Programmer By Christmas!" Sun Exam Study class that has just begun, and they also have monthly user group meetings. The website has all the details, or you can e-mail me. Hope to see you at the meetings! Sue.

J.Pluta

09-21-2000, 07:15 PM

Interestingly enough, Frank, I use all the components of the "WebSphere software platform" (with the exception of Enterprise Java Beans), but I don't consider myself a WebSphere programmer. I am a Java/400 programmer, with emphasis on JSP/servlet technology. Anything I develop with my tools of choice (VisualAge for Java and WebSphere on the AS/400) can be ported to any other tool and webserver, so I'm not sure what the hoopla is about. Maybe I just don't understand enough about it yet; then again, my focus is getting existing systems on the web, not building brand new systems, so I may not be the person to ask. 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

09-22-2000, 12:46 AM

Frank Whittmore wrote: "Here's an article quote. "With this campaign, IBM is attempting to attract 5 million new developers to the WebSphere software platform". That's right. 5 million (with a "M") new developers. Should that include me?" Frank, I'll wear out my welcome if I keep ranting, so I'll just try to add something new to what I've already said, which included quite a bit about Websphere.... A java.sun.com article from this year says there are 2 million Java programmers worldwide. On the other hand, a www.sun.com/SunJournal article "The State of Java Education Today" by Sun's VP of Educational Services Bill Richardson, says there are 200,000 people that claim to be Java programmers worldwide but indications are that a far smaller number can demonstrate effective use of the language. He says that in fact the average Java programmer has less than eight months experience and that two thirds fail the initial Java certification exam. http://www.sun.com/SunJournal/V2N1/04_mgmt1a.html When citing a 5 million number, it is clear to me that IBM is counting anything legacy programmers can slide out as web pages using a Websphere tool as "attracting a programmer to Websphere". Sun estimated a total of 4 million Java programmers by 2003, a million less Java programmers 3 years from now than IBM plans on attracting to Websphere now. When recently reviewing IBM Lotus Notes Domino R5 specs, I wondered how Domino fit in with Websphere. After all, they are both HTTP web servers. It turns out they don't. Not only does IBM acknowledge that the Notes and Domino aspects of the Domino product come from two entirely different directions, one client oriented and the other server oriented, that will be merged someday by having us program in Javascript (I am not making this up), but IBM says that the Domino and Websphere web servers serve two entirely different needs and IBM expects a normal configuration to have both of them running. Also note that both Websphere and Domino are cross platform. They run on NT, HP Unix, and Sun Unix the same as the AS/400. On the one hand, learn to use these technologies and you can use them on any system. On the other, these technologies have nothing to do with the AS/400. Instead of purchasing an AS/400 to run an RPG ERP system, a company must choose whether the AS/400 should be purchased to run Domino Notes and/or Websphere when an NT will run it. Scalability? Unix will run it. Don't get me wrong. I posted 15 unique advantages of the AS/400 in response to a question on as400.misc yesterday, but I wouldn't give somebody very good odds that they could stem the Unix Oracle and NT tide to convince a client/employer to buy an AS/400 to run these cross platform technologies. I wouldn't even give very good odds that a client/employer could be convinced to buck the Oracle Unix and NT IIS tide to choose these Websphere amd Domino products for any platform. We know what the unique advantages of the AS/40 0 and it's RPG ERP packages and industry of business programmers are. Start touting scalablility, reliability, and total cost of ownership to sell the AS/400 as better than Unix and NT to run this cross platform software and you will be met by glazed eyes and the door. So you say, I'll learn these products and it won't matter. Whichever computer system is selected, I'll know the software. But is the Websphere product actually going to be selected by anybody? Check the job ads. How many Websphere jobs are there? How many Domino jobs? Then the response is, well Websphere is open technology. Java, Java ServerPages, Java servlets, web pages, Java applets. It's true that if you nail these technologies down, you have just cross trained from legacy big time. If your clients/employer choose to do anything besides green screens, these technologies will meet and exceed any technology involved. But if it isn't on the AS/400, it'll be on Unix so expect that you'll need to get real comfortable with that. Since I think I've been seeing IBM make noises about pushing free versions of these technologies for Linux, learning all this good stuff by running your Java servelets under Websphere on a PC you set up for Linux will bring you up to speed in a parallel universe. But it's an awful lot to learn when in fact you may be a JDE shop that will choose to migrate to OneWorld, or running on any number of RPG ERPs that go in different direction, maybe ILE RPG, or your shop chooses LANSA or Cool:Plex case tools, or you get into screen GUI'izing with Seagull, or the company decides future development is in Notes and Domino.....all of these having learning curves too. Or we find out that the inevitable doesn't happen... a common interface to Windows and Gnome is created and Windows programming with GUI technologies wins out over the Java thin client revolution. Place your bet, folks. Round and round she goes.... Ralph

Guest.Visitor

09-22-2000, 03:29 AM

Ralph Daugherty wrote: But is the Websphere product actually going to be selected by anybody? There are various components of Websphere that require the entire product to be installed. I have two clients contemplating Websphere for two completely separate purposes, neither of which is the essential Websphere purpose. Client "A" wishes to use a portion of a commerce feature. In order to do this the entire Webshpere product must be installed. Client "B" is migrating from Webulator to Host-on-Demand. Step 2 in this process is to use the "Customizer" for H-O-D. Step 3 in the process is to use the Host Publisher product. Host Publisher requires that Webulator is installed and running. If it weren't for these applications, neither client would have considered Websphere. OTOH this is merely a sampling of my own experience. There must be other components that companies want, and in order to use these components, Websphere must be used. Dave

Guest.Visitor

09-22-2000, 03:58 AM

My experiance with the UK was that there are plenty of AS/400 jobs available but no on wants to travel to places like Scarborough to work.......They want to stay in the Major cities.

J.Pluta

09-22-2000, 06:33 PM

Then the response is, well Websphere is open technology. Java, Java ServerPages, Java servlets, web pages, Java applets. It's true that if you nail these technologies down, you have just cross trained from legacy big time. If your clients/employer choose to do anything besides green screens, these technologies will meet and exceed any technology involved. Amen, Ralph! While I still believe in a long, distinguished future for the AS/400, I certainly haven't hurt myself by becoming Java-enabled. I agree with your assertion that once you know the basic Java/Web technologies, you have a pretty secure skill set, at least for now. But if it isn't on the AS/400, it'll be on Unix so expect that you'll need to get real comfortable with that. Since I think I've been seeing IBM make noises about pushing free versions of these technologies for Linux, learning all this good stuff by running your Java servelets under Websphere on a PC you set up for Linux will bring you up to speed in a parallel universe. True enough. Also, there's a package called VMWare that will run Linux in a window under Windows/2000, so that's another option to learning the OS (I hate dual-booting - bad memories from past lives). I've got it sort of running, but I can't get it to talk to my Ethernet card yet. But it's an awful lot to learn when in fact you may be a JDE shop that will choose to migrate to OneWorld, or running on any number of RPG ERPs that go in different direction, maybe ILE RPG, or your shop chooses LANSA or Cool:Plex case tools, or you get into screen GUI'izing with Seagull, or the company decides future development is in Notes and Domino.....all of these having learning curves too. If you have a choice over what to learn, I would recommend learning a versatile skill set (e.g., Linux, Java and JSP) over a specific tool (such as LANSA). In a shifting market, general knowledge is a better investment than a specific skill. I would especially avoid anything that "generates" Java code; Java needs generators like a fish needs a bicycle. The whole idea behind Java is to write code once and only once. 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