Re: Installing a web change (was: importing a rpg orsqlrpg)

>>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