R1684 responds to a miscellany of reports concerning problems in the CICS
'SPCL' environment.

- I'm not sure whether you know about this, but it's possible to initiate
an action by entering an 'S' next to a function code on the SPCL menu.  The
system erroneously allows OPT1, OPT2, and OPT3 to be selected this way
without identifying the employee for whom the action is to be performed.

- "OPT1 abends on F5 when the employee doesn't exist on the EDB."

- OPT2 abends if an employee has no PCM data.  It should not be possible
for an employee not to have a PCM row (even key change remnants have them),
but if the situation should arise, it should be handled more gracefully.

- The two other error reports are related.  When you enter an online rush
check, entries are written to two different DB2 tables, ABD and ABF.  ABD
contains the information that ultimately will be turned into compute
transactions via batch program PPRCABEY, whereas ABF contains the
information that optionally may be directed via batch program PPRCVNDR to a
campus Accounts Payable or similar system to cut a check.   The reason for
the separation of the rush check information is that the batch programs
which process it run on different schedules.  PPRCVNDR, for sites that run
it, is typically scheduled to run daily, Monday through Friday.  If all of
the data for a rush check were stored together and PPRCVNDR were to delete
it when it's processed the payment, the data would no longer be available
for PPRCABEY later when it's run once per compute.  Splitting apart the
data makes it possible to retain just the portion that's still needed and
allow the two batch processes to run asynchronously.

One of the error reports notes that modifications via function code RCOV to
the ABD table are not carried over to the ABF table.  The other notes that
when function code RCAD is used to delete a rush check from the ABD table,
the corresponding data remains in the ABF table.  Three of our sites
(Davis, San Diego, and Santa Barbara) run PPRCVNDR and are affected by
these problems.  All three have local modifications in program PPAPORUP to
address the rush check deletion issue, and with the implementation of r1684
will be able to return those sections of code to the Base version.

A curious feature of the design of the ABD and ABF tables is that there is
no sure fire way to relate a rush check entry in one with the other.  One
can make a good guess based on employee id number, but it's not a
certainty.  The local mods in PPAPORUP don't take into account the rare
possibility of there being more than one rush check for an employee.  In
r1684, Base Payroll addresses that possibility by adding a check number
field to the ABF table to "allow the data to be associated with
corresponding data on the PPPABD table so that related records can be
updated in and deleted from both tables."

There are no table updates for r1684.

Testing of r1684 is complete for all sites and we're ready to install as
soon as we receive your ok.

   bvb