Is the new WebFacing tool the first step to Web enablement?

[J.Pluta]

Is the new WebFacing tool the first step to Web enablement?

Do converted applications enforce restrictions on the browser? For example, are the and buttons disabled? Is the URL box disabled? What if the 5250 back-end is waiting in one state, and the user were able to jump to a different state, leaving the 5250 application in limbo? I believe you're going to have this problem with any attempt to move a traditional green-screen application to a non-captive display. I'd be interested to hear what you (or anybody else) would consider a viable solution to this particular problem. For me, I plan to disable forward, back and URL when I'm in the midst of a legacy application. I can't see any way around it without major changes to the program. Joe

[R.Daugherty]

Is the new WebFacing tool the first step to Web enablement?

Hi Nathan, I see why I haven't run across that much on Webfacing... it's still in a pilot stage. IBM does contrast the Host On Demand product I was referring to as being more complex to port to. On the other hand, they say that if you're in the Webfacing pilot program you must give them a list of DDS keywords that you use and they'll tell you which ones are supported and attempt to add others on an ongoing basis. I don't know if this is limited to the pilot program or just how much support they expect to have before releasing the product (it was stated 2nd quarter 2001... is it already released? is that why we're talking about it?) On a related note, IBM says that 76% of new AS/400 sales are for running new e-business software... whether the customer knew they were getting a crippled machine or not.... Ralph

[R.Daugherty]

Is the new WebFacing tool the first step to Web enablement?

Dave wrote: "Your typical AS/400 shop may not have the budget, or the resources." Hi Dave, The point was that it was done in that timeframe because they integrated to a commercial catalog package instead of starting from scratch. The work was done by one independent consultant in the Seattle area who is a JDE specialist. BusinessLink did also add a couple of things to their product in the same timeframe to meet customer requirements, which they also did for me when I was a customer. The Fortune 100 on the East coast had an AS/400 JDE staff, but chose to outsource the website development given the time constraints. The consultant was a verteran JDE RPG programmer and had no experience with the web. He just interfaced the catalog files to the JDE files. It was a real time integration site, not a copy file site, and although I didn't go through the code with him in detail, the integration specified where the caalog code was to retrieve information and what calculations to perform on it. Thanks for the comments, Dave. Ralph ralph@ee.net

[David Abramowitz]

Is the new WebFacing tool the first step to Web enablement?

Ralph Daugherty wrote: a major successful implementation of interfacing to a Fortune 100's JDE World was done a year ago and put into operation in the three month timeframe that the CEO had demanded That's O.K. for a Fortune 100 company, where the allocation of resources, and budget are not a problem. Your typical AS/400 shop may not have the budget, or the resources. Dave

[David Abramowitz]

Is the new WebFacing tool the first step to Web enablement?

Ralph Daugherty asked: how many companies would buy an AS/400 as an $115,000 web server? I am totally confused. This is a great point. Companies not currently using the AS/400 would not pony up this price just to get a web server. Companies using the AS/400 would want to integrate their existing apps with web serving capability. IMO, the existing apps, are indeed the meat and potatoes of a firm's business. Web serving is something new. If it is an experiment, then a firm is likely to have static pages, where no integration is necessary. A small anything box would suffice. If a firm dives in to the deep end, access to the database is essential, but that does not negate the need for interactive processing. The "system" models provide both functions superbly well. OTOH, a new customer seeking to develop client applications only might do well to spend the bucks. They will get 64 bit power, and an integrated ANSI-SQL compliant RDBMS as a base for their client applications. Using the same box for web serving should not be an issue. OTOOH, CFINTxx may kick in for batch procedures. IMO, the bottom line is that IBM can make a profit without the "interactive tax". Drop the price; eliminate CFINTxx; Simplify, by offering only a single line of models; Avoid the confusion; Avoid the problems. Dave

Is the new WebFacing tool the first step to Web enablement?

According to the article I referenced in the beginning, Webfacing generates JSPs (i.e. HTML) - not AWT components. Thanks for the comment, though. Nathan.

[R.Daugherty]

Is the new WebFacing tool the first step to Web enablement?

Hi Nathan, Many good questions you have been raising. My recollection was that with both Jacada's and IBM's conversions, the output was Java code (AWT?) that, in Jacada's case, could be modified and enhanced, and in IBM's case, could at the least be enhanced to call additional code. IBM has too many things going for me to stay on top of. Is the Webfacing stuff being discussed strictly HTML output, or is the output for Java AWT clients? The reason I ask is that the difficult conversions you speak of are a different beast altogether if the conversion is to a Java client (source code generated in Jacada's case, or a Java client product with exit calls in IBM's case). Of course, if I'm mistaken and this is some super duper upgrade from 5250 Gateway web pages, then I would like to see what the constraints of the conversion are. Ralph

[R.Daugherty]

Is the new WebFacing tool the first step to Web enablement?

Frank, I can't imagine how your requirements justify a more costly solution than the many web catalogs that are out there. I was slightly involved with Advanced Businesslink's catalog software which requires their Strategi web server ($4,000?), IBM advertises their's extensively which requires Websphere, and I would be surprised if Lansa didn't have one for there web server as well as others, I just don't know how many run on the AS/400. I know that with BusinessLink's, there is an Integration module that is part of it that is used to interface to legacy code (such as RPGIII programs) and that a major successful implementation of interfacing to a Fortune 100's JDE World was done a year ago and put into operation in the three month timeframe that the CEO had demanded. It is a B2B site for their dealers, so it isn't available to the public, but I can't imagine how your requirements would exceed such a catalog site. All the basic work is done but screens can be modified, RPG business logic added, etc. What do you think? Ralph

[R.Daugherty]

Is the new WebFacing tool the first step to Web enablement?

"Keep in mind that the "green screen tax" doesn't apply to e-RPG apps (I don't believe - someone correct me if I'm wrong)..." Hi Brian, Your comment and the recent comment about interactive document searches being slowed down by the IBM governor (by the way, I personally would never participate in IBM's scheme - I would pay for a real AS/400 and if IBM's price gets too high it will do nothing but cost justify a conversion, and I assure you it won't be to anything else made by IBM) reminded me of some of our discussions concerning messaging architecture. I tested the AS/400 jobs web site back end I wrote (still unbelievably unimplemented after nearly a year due to customer being too busy with other priorities) with calls from green screen programs, and the thought that occurred to me is that all of the work is done in a batch subsystem, even when invoked by calling a program which interfaces to the back end dataq server programs. I am thinking that the work doen in the batch subsystem doesn't reflect in the interactive session at all and thus both web pages and green screen would be served by same programs that would never invoke the green s creen tax, as it would take hundreds of such interactive sessions to have much measurable impact when all they are doing is relaying data back and forth via messages. In which case, either I'm wrong, or IBM will move to measure such interaction, or moving business logic and database access to a batch subsystem and communicating via dataq bypasses IBM's green screen tax, which I have no idea why that makes IBM so happy. And while the discount was 50% based on the figures given, how many companies would buy an AS/400 as an $115,000 web server? I am totally confused. Ralph

[frankgw@adelphia.net]

Is the new WebFacing tool the first step to Web enablement?

Brian - Thanks for taking an interest here and sharing your knowledge. "What do you want to do with the website?" We're talking a B2C web site. (business to consumer) If it's just brochure-ware, we want lots of brochure-ware. Most of this data currently resides in an Apple LAN. If it's to be an e-commerce site, we're talking 25,000 to 30,000 inventory items. Most are priced well under $10 each. Some can be pricey. What do you think your volumes will be? Let's say 50 orders per day with 20 items per order. What levels of integration with current systems? High - otherwise we'll end up duplicating our complex RPG business logic (Order Entry & Inventory) into the front-end web site. What skillsets do you have within your shop that you'd like to use for this project? Very good RPG skills in house, but no web skills at all. Looks like we'd need to outsource the initial web site development. We're talking a small one programmer, one programmer trainee, one query expert, one PC/LAN expert and one I.S. manager shop. O.K. everyone. Fire away!

Is the new WebFacing tool the first step to Web enablement?

A couple of points raised in this discussion have been valuable to me.  One is the "interactive tax" concern.  But also that a shop might eventually work toward disconnecting the "generated" presentation layer from IBM's Workstation Manager to solve that problem.

Still, many questions come to mind.  Is this the type of tool that one might use for new software?  Or only to convert existing applications?  For example, would a developer create a new green screen program, then use it as a base to generate the "web face", then deploy the GUI?  Or, both?

Do converted applications enforce restrictions on the browser?  For example, are the and buttons disabled?  Is the URL box disabled?  What if the 5250 back-end is waiting in one state, and the user were able to jump to a different state, leaving the 5250 application in limbo?

Actually, the whole idea of taking a green screen program, and generating there from, an HTML text stream, seems like a technical marvel.  Consider the number of record formats in many screen files.  They may overlay different areas of the screen.  They might be output independently of the others.  Many newer 5250 applications deploy windows, and drop-down menus.  It just doesn't seem to map to an HTML stream cohesively.

I've appreciated the input so far.

Nathan.

Is the new WebFacing tool the first step to Web enablement?

Hey Frank, We need more information before we can begin to argue about what your strategy should be :-). What do you want to do with the website? If it's just brochure-ware, you might try getting it hosted somewhere. If it's to be an e-commerce site, then the requirements will be different. Keep in mind that the "green screen tax" doesn't apply to e-RPG apps (I don't believe - someone correct me if I'm wrong), so that's not a consideration in this case. What do you think your volumes will be? What levels of integration with current systems? What skillsets do you have within your shop that you'd like to use for this project? Etc. Regards, Brian Singleton

[frankgw@adelphia.net]

Is the new WebFacing tool the first step to Web enablement?

Joel said - "Omigod!" First, thanks to Nathan for starting this thread and to all those that have participated so far. To Joel - my first reaction to all this, I will not even attempt to document. Let's just say it's stronger than "Omigod!". I attempt to manage a traditional shop that is still 90% plus custom RPG code as far as the AS/400 model 170 is concerned. There have been several requests to add green-screens in the past few weeks. For the first time I found myself trying to put the "green-screen tax" card into play. Yes, we do have a PC LAN. The AS/400 is attached to that LAN. The LAN server is a Dell PC Server running Novell's Netware. The boss says "we need a web site". Oh yeah! We also have a Apple Mac separate LAN. That's where product images and lots of product descriptions are stored, but of course the main Order Entry, Invoiceing and Inventory are over on the AS/400. Some days I feel like I'm shoveling sand against the tide using an old pitchfork. Does anyone want to take a shot at what our shop's strategy should be for the next few years? I'm all ears or should I say eyes?

Is the new WebFacing tool the first step to Web enablement?

>>If it creates and uses Beans, doesn't that mean you need the $10,000 add on for WebSphere?

Are you referring to the Advanced Edition of Websphere? If so, it is only required for Enterprise Java Beans. Regular java beans will work in the Standard edition of Websphere. Dean Eshleman, MMA, Inc.

Is the new WebFacing tool the first step to Web enablement?

If it creates and uses Beans, doesn't that mean you need the $10,000 add on for WebSphere? And where did IBM get the idea that we want or need to web-enable ALL of our applications? They may not explicitly say so, but that's exactly what the "green-screen tax" is all about! We just priced a mid-level 270...the cost of the machine was into the $80ks...until we took off the Interactive piece. Saved us $50k. "Omigod!" was all I could say - good thing that box was INTENDED for web development. As I'm sure most of you know, I'm all for using the 400 as a web development platform. I'm proud of the work we've done and I have big plans for future web products. But why should that mean I have to do EVERYTHING on the web or pay the price? If we *had* to actually replace/upgrade/modify our legacy apps to be web enabled it would bury us (and a bunch of our clients) forever. Everyone who WANTS a stop-gap solution, raise your hand...anyone? anyone? How about exhorbitant fees for services we all rely on...anyone? anyone? Bueller? Off the soap box and back to work...gotta get Tomcat installed on my PC so I can do some .jsp/servlet stuff (sans IBM...) Ciao, Joel