Release 1624 responds to an error that Davis initially brought to our
attention, but I later discovered affects nearly every payroll site.  It's
subtle and may not have come to your attention because it's in an area that
we don't look at very often, specifically the contents of the UC0IDB table
in the IID database, which stores identity information (employee id number,
name, SSN, and birth date).  The problem affects only names in IID.  Id
numbers, SSNs, and birth dates are fine.

The IID database was designed to be used and maintained via CICS only, not
through batch processing.  If you perform an online new hire or name or SSN
change, behind the scenes programs are invoked to ensure that those changes
are propagated to the IID database as well as entered in the EDB.  Later,
just one, limited batch IID interface was added, and that's where the
problem lies.

Employee Self Service offers employees the ability to change their own data
on the web.  All those payroll-related web entries are turned into batch
transactions in the FTPUSRx.GET.IVRNH file to be processed five nights a
week by PPP130 in an abbreviated form of batch EDB file maintenance.

At first the employee-entered transactions were limited to those suitable
for newly hired employees, hence the name IVRNH = IVR New Hire, nor was
there any connection with IID data.  Later the options were greatly
expanded, and among those IVRNH transactions are occasional name changes,
coded as N1 and N2 transactions, which require IID updates as well as EDB
updates.  (R1253 in 1999 added the IID support.)  When processed by PPP130
in a type 5 update, these transactions apply changes to first, middle,
last, and/or suffix portions of an employee's name in both the EDB and
IID.    Typically only one of the four fields is modified.  The size of the
component fields is such that two transactions are required to accommodate
an entire name, but if only the last name is changed for an employee, only
an N2 transaction is created whereas if only the first name is changed,
only an N1 transaction is created, and so on.

When these batch N1 and N2 transactions are processed, names in the EDB and
IID are correctly updated for the specified employee.  The problem is that
the same name change is applied to additional employees in the IID who
never should have been touched.  As an example, if an N2 transaction were
processed to change Joe Doe's last name to Smith, an unpredictable number
of other employees would have their last name changed to Smith as well -
but only in the IID database, not in the EDB.  The same behavior occurs for
changes to first, middle, and/or suffix portions of the name.

We identified the 'other' employees, who should not have been changed in
IID, as all those who also had IVRNH transactions -- of any kind -- in the
same batch and whose employee id numbers were higher than an id with a
legitimate name change.  This occurred because an internal storage area
used to pass data between programs was not cleared out between employees,
so PPP130 thought it had additional employees for whom name changes should
be applied.  The fix in r1624 is literally a one line re-initialization of
the storage area.

There are no table updates.

CONSEQUENCES AND IMPLEMENTATION

The batch IID interface referred to above was enabled in 1999, however we
didn't implement IID processing for our sites (except for ASUCLA which does
not use it) until approximately 2000-2001, with the date varying by
site.  The errors have been occurring since IID processing was first turned
on, but you wouldn't be aware of the incorrect name data unless you
happened to do a hire and were presented with a list of employees from IID
who the system thought could potentially be the same person, e.g., have the
same SSN, and it happened to include one of those with incorrect
data.  Even then, unless you happened to recognize those 'possibles', you
wouldn't necessarily realize that a portion of a name was
incorrect.  That's why the problem has been present for such a long time
without it being realized.

I ran some matches between EDB and IID yesterday, and came up with these
counts of employees with name differences.  Some of the variation in
numbers can be attributed to the number of employees at a site, but it goes
beyond that.  Culturally there may be greater or less use of Employee Self
Service features by employees at a particular site, and the more activity
there is, the more IVRNH transactions there are, and that ripples over to
more employees whose names were inappropriately updated.

DV - 7315
RV - 258
SD - 5773
SC - 213
SB - 530
AS - none (not using IID)
HA - 3

I recommend that we install r1624 as soon as possible after completion of
testing so we can prevent any further incorrect name changes.  The next
step, now being discussed by Base Payroll and Payroll Coordination, will be
to correct the erroneous entries.  The general thinking at this time is
that when there is a mismatch, we should assume that the EDB contains the
correct name.

Ok to proceed?

   bvb