Oracle Retail jobs ending with a 'ready for start' status are treated as erroneous ending

Document ID : KB000089601
Last Modified Date : 14/04/2018
Show Technical Document Details
Issue:
Oracle Retail jobs ending with a 'ready for start' status are treated as erroneous ending
Resolution:


Appliesto Applications Manager version 7.x and 8.x

Symptoms

Some Oracle Retail jobs are finishing with the status of 'ready for start' instead of 'completed'. These jobs are then treated by Applications Manager as ending in an error, as their status is not 'completed'.


Cause

In the upgrade v13.x of OR RMS this is a known issue.  Here, the finishing OR programs update the status - technically it could be argued that this is an Oracle design bug, as a job that is completed should show as such, and when the program starts, only then should it verify the last run status, then change it to ready for start - this is what the AM RETAILP program essentially does.


Resolution

to solve this, there are editable entries with in the $AW_HOME/data/awserver_sqlusr.dat file (the AM customer/solution api file), that can include these exception jobs. Currently it caters for the following:

'ociroq', 'saimptlogi', 'saimptlogfin', 'saexprdw', 'rplext', 'salprg', 'fdaydnld','precostcalc', 'posupld', 'sapurge','saexpim','saexprms', 'sastdycr', 'sapreexp'

The entry in the awserver_sqlusr.dat code looks like this:

4007 RETAIL_CHK_STATUS SELECT 10000 0 OBD_CLS_COM_CONT NULL FETCH_ROW

so_module,threads#result#

select 'Thread '||to_char(thread_val)|| ' ended with status '|| program_status result

from restart_program_status

where lower(restart_name) =lower(:so_module)

and ( (program_status not in ('completed', 'aborted', 'aborted in init',´'aborted in process', 'aborted in final')

and restart_name not in ('ociroq', 'saimptlogi', 'saimptlogfin', 'saexprdw', 'rplext', 'salprg', 'fdaydnld', 'precostcalc', 'posupld', 'sapurge', 'saexpim', 'saexprms', 'sastdycr', 'sapreexp') )

or (program_status not in ('ready for start')

and restart_name in ('ociroq', 'saimptlogi', 'saimptlogfin', 'saexprdw', 'rplext', 'salprg', 'fdaydnld', 'precostcalc', 'posupld', 'sapurge', 'saexpim', 'saexprms', 'sastdycr', 'sapreexp') ) )

and :threads = 0

union

select 'Thread '||to_char(thread_val)|| ' ended with status '|| program_status result from restart_program_status

where lower(restart_name) =lower(:so_module)

and ( (program_status not in ('completed', 'aborted', 'aborted in init', 'aborted in process', 'aborted in final')

and restart_name not in ('ociroq', 'saimptlogi', 'saimptlogfin', 'saexprdw', 'rplext', 'salprg', 'fdaydnld', 'precostcalc', 'posupld', 'sapurge', 'saexpim', 'saexprms', 'sastdycr', 'sapreexp') )

or (program_status not in ('ready for start') and restart_name in ('ociroq', 'saimptlogi', 'saimptlogfin', 'saexprdw', 'rplext', 'salprg', 'fdaydnld','precostcalc', 'posupld', 'sapurge', 'saexpim', 'saexprms', 'sastdycr', 'sapreexp') ) )

and :threads != 0

and thread_val = :threads

Adding the identified "ready for start" status jobs within this should by-pass the checking. The AM system should be completely stopped and restarted after editing (as the sql routines are cashed and re-initialised on startup).