Subject: | |
From: | |
Reply To: | |
Date: | Sun, 6 Nov 2005 21:24:24 -0800 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
This follow-up is to issue a correction to a statement I made in the
description of r1668. Although the ARSM Personal rule is checked during
web merit processing, it is not used to block updating of a user's own
record. Instead, a notation that it happened is recorded in the DB2 MLA
table for audit purposes. Carol Houchens at Santa Barbara advised me there
was much debate about this subject during the design phase of the project,
and Kathy Taylor in Base Payroll confirmed this departure from the usual
PPS protocol.
bvb
------------------------------------------------------------
Date: Tue, 01 Nov 2005 22:27:03 -0800
From: Barbara Vanden Borre <[log in to unmask]>
Subject: payroll release 1668
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
|
|
|