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

> From: Mark Phippard
>
> Once a web application is installed, virtually any change can be
> "hot-deployed" by just copying in the changed files.  WebSphere will pick
> up the changes and automatically restart.

This is the interesting phrase - "automatically restart".  Restart what?
Surely not the entire application server.  The application?  Or does it just
reload the affected classes?  Remember, a typical web-faced display with,
say, four record formats requires about 20 objects.  So those 20 objects get
reloaded - how can you be sure somebody doesn't accidentally get the old
version of one object and the new version of another?  I hate black boxes.
I suppose it's just timing and keeping your fingers crossed that nobody
actually accesses the system while you're changing files.  And of course,
woe to anybody who is actually USING the application while this occurs -
what happens then?


> Exceptions are mainly when
> creating new EJB's.  New/changed servlets or JSP's are a piece of cake,
> even most changes to the web.xml.  IBM has documentation for each type of
> change being made what has to be done.

Where in the documentation?  I need to take a look at that.


> When using TurnOver in WDSC, TurnOver automatically keeps track of all of
> the files being changed.  When you tweak something in WebFacing, and
> suddenly 100 files were changed, TurnOver knows about every one of them.
> You can then just drag n' drop those changes to your TurnOver worklist and
> promote them.  The same promotion could include RPG/DSPF/PF/LF, doesn't
> have to be just web objects.  This would also allow you to back out the
> changes in tandem if necessary.

So you use a manual (drag and drop) intervention that basically subverts the
EAR/WAR deployment process.  Okay, better than the export/uninstall/install
procedure, I suppose.  But I assume that TurnOver isn't free, right?


> If you want to, you could even use the WebSphere commands we developed to
> stop and start the server or your application as part of the
> promotion, but that is usually not necessary.
>
> Anyway, you could do all of the manually.  The hardest part would be
> identifying what you changed, especially with WebFacing since so much is
> done invisibly.

See, with PSC/400 you don't have any of that.  PSC/400 is designed by
developers and meant for industrial strength development.  One JSP per
display file rather than two per record format.  One .dat file that is
dynamically loaded at runtime rather than dozens of individual classes.  A
common servlet for all applications that is part of the single JAR file for
the entire runtime.  (All of which, by the way, make the JIT compiler work
much better for PSC/400.)  When you run my CNVPGM command, it simply
regenerates the JSP and recreates the .dat file, right in place.  With
WAS35SE, WAS4 or Tomcat, it picks up the changes automatically, and from
what you're saying the same thing is true with WAS5X.  Cool.  So PSC/400
basically provides as part of the base product what TurnOver provides for
WebFacing.

And TurnOver, or something like it, has got to be required for WebFacing in
any sort of production environment, because development using standard EAR
and WAR files is not suitable for a normal production environment.  That
"install" process is about the ugliest thing I've ever seen - one more clue
that the EAR/WAR design was created by people who never really worked in
application development <grin>.

Joe