This release addresses a long-standing, but infrequent, glitch in the
online display of PAR data.  As you know, each PAR record contains
a field called the Priority Gross Control Number which functions as a
sequence number.  The first time a newly hired employee is paid, the
value in his or her PAR record is set to 001.  The next time a PAR
record is written for the employee (sometimes there are multiple records
in a single compute), the value is set to 002, then 003, and so on.
The last assigned value is stored in the EDB as well.

Over time, for employees with a long history at a payroll site, it's possible
to reach the highest number (999) that will fit in the Priority Gross Control
Number field.  The next time a PAR record is written for such an employee,
the numbering rolls over to 001 and continues with 002, 003, ....

In CICS when you select a function for viewing of PAR data, you should
initially be positioned at the most recent record.  How do we know which
is the most recent?  Currently we assume that it's the one with the highest
numbered Priority Gross Control Number.  That works fine in most cases,
but not when there has been a rollover from 999 to 001, and the most
recent data has a lower value.  That's the problem addressed by r1642.

The solution is the addition of a new sequencing field (PAR_SEQ_NO)
in the EUD table of the DB2 PAR which is calculated based on a
combination of Priority Gross Control Number and Pay Period End Date.
** The sequential PAR file is not changed in any way. **

Three basic components of the release are:

1 - A DB2 structure change to add the new field, including a new index
     to support speedy access to the data.
2 - Modification to batch program PPP465 which is used to load
     sequential PAR data into the DB2 PAR database.  It will now
     calculate PAR_SEQ_NO values for every EUD record in the database,
     not just those being added, and you'll see two new counts at the
     bottom of the PPP4651 control report:
       TOTAL EUD ROWS UPDATED
       TOTAL EUD ROLLOVERS ENCOUNTERED
3 - A long list of CICS programs used for display of PAR data is modified
     to use PAR_SEQ_NO instead of Priority Gross Control Number for
     sequencing the data correctly.  The new field is *not* added to the
     screens, and therefore the modification will be transparent to users
     except for the fact that data for 'rollover' employees will now be
     presented in the right order.

R1642 also includes an incidental fixit for the ICHK and IDCS screens
related to display of message P0304 (Displays Current Activity Record
Type only).

There are no table updates.

Frequently when a new data element is added to the system we are
given a one-time program that will establish appropriate initial values
for it.  In this case, PPP465 itself will take care of initializing
PAR_SEQ_NO.  The installation instructions call for us to run it
with no input to derive the new values.  We will call this special job
'PP*R1642' and its output control report file 'OT16421' to differentiate
it from regular PPP465 processing, however the report header will
show 'PPP4651' just as it normally does.

I think that when you first read the release letter and look at the list of
programs being modified and see that a DB2 structure change is
required, this looks like a big deal.  In fact, from the end user
perspective, in nearly all cases it will be invisible.

May we have your ok to install r1642?

   bvb