Verify Ack Hold Batch Process

NOTE: If a ticket for this issue was sent on a holiday, you can ignore the message. There are no trasaction on days the business is closed, so the scripts flags this a false positive. 

Script ack_hold_reset.ksh is scheduled to run @1300. Planners are aware of this schedule, as there cutoff time.

Run a query on table C_ACKRLF to see if there are records processed by PAH user (A system process) 

• select * from c_ackrlf where opr = 'PAH' and proc_date = trunc(sysdate)
• If you don't have TOAD, you can log into UNIX using PuTTY, and use Unix script /scripts/checkackhold1. 

If there are no records returned, check to make sure there are no locking going on. If there are no locking, verify script ack_hold_reset.ksh is no longer running (issue unix command ps -eaf | grep ack_hold_reset.ksh). If batch is not running anymore, immediately schedule this update script - ack_hold_reset.ksh - to run again either in cron or command line as root.

After re-running batch script, run checkackhold1 again. If it returns

records, then we are ok. If it did not return any records, then run script below to

verify if there are records to be reset today. If it did not return any records,

then no need to run the batch job.

This second script is to verify if there are records waiting to be

processed by this update. select * from c_asolin where sales_ccn = 'HG0101'

and ackhold_upd_date <= 'date here' and ackhold_reset is null and

ackhold_hlddte is null -> this is to verify if there are orders to be

reset as flagged by planners and analysts. If there are records returned,

then reset script needs to be run again. If you don't have TOAD,

use Unix scripts /scripts/checkackhold2

If this was sent on a holiday, ignore this message.

If you are now getting records from script no 1, make sure to inform Phyllis or

planners that the ACK Reset hold process that normally runs @1300, just ran now.

Common cause of this not running is a deadlock on oracle side.