View Full Version : What technologies interest my AS400 colleagues?
01-01-1995, 02:00 AM
After reading recent blurbs from Roger Pence and the like I find myself finally coming to terms with the fact that the end of the AS400 is in sight. Here in the UK the AS400 job market is a sickly beast indeed. I'm on less than I was 3 years ago but am grateful just to have a job, there are plenty of experienced AS400 staff around without one. The contract market is virtually non existent. So what next ? I've dabbled in AIX but couldn't face a career in it. Who wants to ride a carthorse after being astride a racehorse for 12 years? Don't even mention Windows, if I wanted to be in the 'bodgit and scarper' trade I could have become a builder! Java looks interesting but I can't help wondering if it's over hyped? What technologies do my AS/400 loyal colleagues get excited about? - which disciplines can you contemplate working in after all this AS400 time?
09-15-2000, 06:24 AM
The 400 situation is the same here in Canada. The shop here is slowing down to nothing (In preperation for possible move to Unix in US). I've been looking around for about a year but like your area, full time and contract work for experience RPG is hard to find. Shops are looking for 5 years experience or less for RPG (probably because of the salarie) I've been into Java for a while at home because I believe the web will be the way to go. Also HTML, Net.Data macros, CGI objects look interesting for interfacing with the 400 on a browser.
09-15-2000, 08:07 AM
Could you please translate 'bodgit and scarper' into English; Neither appear as such in the OED. bobh
09-15-2000, 08:21 AM
"Java looks interesting but I can't help wondering if it's over hyped?" That sentence appears as though you haven't taken a serious look at it. There's only one way to answer your question and that's for you to take the plunge and see for yourself if you believe it's over-hyped. The question isn't really if it's over-hyped or not, the question is can applications built with Java meet the requirements of today's enterprise? The answer, for me, has been a very resounding "YES". The biggest gripe I have of AS/400 professionals I know of (I'm not picking on you) is that if there is the possibility of a new technology entering their lives, they seem reluctant to simply evaluate it for their needs or even outright resistant. RPG for ILE and Java are two great examples. I would emphatically encourage you to pick up a book or two on Java (Don Denoncourt's book is an excellent springboard for AS/400 professionals), become familiar with it through sample-type programming and then use it in a small project. Before you know it, you'll be an e-commerce expert in great demand. One thing I run into quite frequently in AS/400 shops implementing Java e-commerce projects is that they typically bring in Java/OO programmers to work with an AS/400. AS/400 personnel are given the "don't call us, we'll call you" treatment but are the ones who usually have the greatest skill in business application programming. Do yourself a favor, add the e-commerce development skill of Java to your biz-app skills and see for yourself how much your new skillset will be in demand. Don't keep "wondering". Best wishes.
09-15-2000, 08:58 AM
Hi Guys, Thanks for your comments. 'Bodgit and Scarper' - that's a term coined by a colleague of my mine referring to Windows support types. Got a problem - they come round (eventually) fiddle around and get you working (until the next time you reboot) - this is the 'bodge'. They then run off to 'fix' another problem (this is the 'scarper') and you wait another day for them to come round and repeat the process. Apologies to any real Windows pros out there - I'm sure there must be some! (Yes I think I'm a little bitter). Jeff, I have actually been on a Java course (self financed). But have since done nothing further. Thanks for your encouragement - I'm going to do some Java on the 400 as a first tentative step.
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
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
09-15-2000, 02:31 PM
I agree wholeheartedly with the kinder, gentler Joe Pluta!
09-15-2000, 06:18 PM
09-16-2000, 10:33 AM
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 <u>Wall Street Journal</u> and <u>Barron's</u> 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
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.
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
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
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
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
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.
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.
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
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).
09-18-2000, 03:07 AM
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
09-18-2000, 05:16 AM
Susan Behrens wrote: Domino was free to us Sue, How did you manage this one? Dave
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.
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.
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.
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?
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
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.
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
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.
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.
09-18-2000, 10:01 AM
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
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)?
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.
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
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.
09-18-2000, 03:51 PM
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.
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
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
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
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
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.
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.
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==
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolki
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolki
09-21-2000, 01:33 PM
Susan, Would you please send me some info about this User's Group? Thanks. MichaelD firstname.lastname@example.org
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?
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.
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
09-22-2000, 12:46 AM
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
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.
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 <font > color=red>FREE</font> Java/400 Client/Server <font > color=blue>Revitalization</font> Toolkit
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.