|
>>I updated many individual panels without having to >>restart the web module. >Um, that's not WebFacing. That's WebFacing plus Buck >Calabro's custom CL. Windows drag & drop works great if you prefer a mouse, as does the DOS XCOPY command if you don't. I use CL because I'm an iSeries guy at heart. The point is that WF is not at all limited to the WAR file deployment model. >So, everybody who uses WebFacing has to basically >learn the tool to the degree you did It seems to me that understanding how things work is the basic job of a programmer. It took me less than an hour to figure out where things go. After all, programmers do it every day putting the appropriate RPG programs, display files, logicals, etc. in the right library, on the right system. "To the degree you did" took me under half an hour of looking at the directory tree. >> In PSC/400, that would mean replacing the JSP and XML together. >> If we managed to replace the JSP, then a request >> comes in and served, the XML is out of synch, not having been >> replaced yet. > >Not true. The XML is only loaded when a program is first run >for the life of the app server, or after a reload. Synchronization >is simple in PSC/400 - replace the XML first, then the JSP. Flip the >application reload switch. Done deal. The JSP BY DESIGN will not be served >until the XML is reloaded. But it's already been served. The JSP has already rendered an HTML page, which somebody is looking at. The back end RPG program has been changed; the parameters to the API calls are different than the form on the HTML. The user presses Enter and there's a mis-match. Multiply that by the number of programs my A/P application needs to be in synch and I comfortably stand by my original statement that this _coherence_ problem is common to all platforms and all vendors. Which is a large reason customers don't install ver 1.2 over the top of ver 1.1 during work hours. >I'm sorry, Buck, but I consider your expectation level for >WebFacing to be extremely low - closer to a Microsoft >product than an IBM product. I'm not at all sure how to respond to this. Above, I'm a genius for discovering the arcana needed to deploy WAS objects and here I'm a schlub expecting dreck and happy to get it. I'm not sure how my expectations come across, but in the area of deploying a series of changed objects, my expectations are very similar to green screen. Off-hours install of new version (many objects), driven by a script. Emergency installs by script or even by hand, expecting that user requests which occur during the install process will fail. I expect that the rest of the system stays up. Just as if I'm installing changes to purchase orders, I expect A/R to continue serving users, but I understand that people asking for the purchase order system may see level checks during my emergency install. I have no pecuniary interest in IBM or WebFacing. I do have operational experience with WebFacing 5000+ display files and deploying them to WAS. I also have operational experience changing the underlying RPG and DDS as well as changing the formatting JSP files in place. I have experience updating single panels as well as a bulk upgrade of all panels as well as installing ver 8.1 over the top of 7.5 (roughly 20% of the panels changed.) As far as deploying them to WAS goes, I ran into about the same amount of effort as I did deploying the exact same green-screen-only changes into my personal test environment on the iSeries. Part of my job was to keep the green screen side completely synchronised with the Web side, and while this was not in use by thousands of users, I had no qualms with the sales force running demos with it at any time. From a deploy/install/upgrade point of view (the topic to hand,) my experience with WebFacing is very similar to my experience with green-screen. Respectfully, --buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.