This release consists of changes to java code used for web merit processing
and can be skipped for ASUCLA and Hastings.  What we have here is a
positive, corrective response to issues that have been reported by various
payroll sites, some of them ours:

- SF reported 'session bleeding' in which one user could see
   another user's data.  At least anecdotally this seems to have
   happened to Riverside and Santa Barbara as well.

- I reported this one:  unlike CICS regions which are
   stopped and restarted on a daily basis, the Websphere/java
   environment in which web merits runs is up pretty much
   continuously.  Weeks or a month could go by, and eventually
   (in our case very early on Sunday mornings) DB2 on the
   mainframe is briefly shut down and recycled for backups,
   etc.  The next person to begin work in each site's web merit
   environment, usually on Monday mornings, will then encounter
   a 'stale connection' and will abend.  It's only the first person
   who is affected; a second try or access by anyone else afterward
   will be just fine.   R1668 builds in a self-test of the connection
   to DB2 on the mainframe and issues a re-try if needed, so
   users will not experience the stale connection.

- Riverside reported that 'Up' buttons on merit rosters
   sometimes do not work.  It was discovered that this happens
   only when a department code begins with leading zeroes.

- Riverside demonstrated in testing that a web merit user
   could update his/her own roster entry.  The design of web
   merits was intended to work exactly as it does in CICS to
   prevent updating of one's own data based on an ARSM
   'personal' rule, but a 'self update' flag was not being
   properly set in the DB2 MLA table.

Release 1668 is designated as urgent, but it probably depends
on where you're at in web merit processing.  Congratulations to
Santa Barbara for being the first site to use web merits live in production!

Ok to install?

   bvb