Provide a customizable HourGlass ACES Refresh and Stop Delay Time Parameter

HourGlass changes the local time for selective applications that take part in a time journey. The HourGlass ACES table contains the jobnames of jobs that are to run with an altered time and is in ECSA storage.
When performing a dynamic ACES replacement ("refresh") there is a hard-coded delay value in HourGlass code to allow running TCB's currently processing a TIME call to finish their TIME call within this delay time before the old ACES storage is released. This delay ("short delay" in the APAR text) was introduced by HourGlass APAR PM47071.
However sometimes a short delay is not enough for jobs that might have been swapped out during their TIME call. If this happens, the affected job or STC suffers from an abend0C4, causing HourGlass recovery code to stop HourGlass processing on the whole system, which leads to jobs taking part in time journeys to run with inconsistent time values.
This poblem is addressed by the current RFE.

The same problem even combined with a potential common storage overlay can arise when stopping HourGlass and freeing ECSA strorage. A later swapped-in TIME caller that had been processing HourGlass code can try to store data in this possibly already resused piece of ECSA storage. A PMR for this aspect can still be opened.

So we suggest to use the same or a different customizable delay value for refreshing the ACES and for stopping HourGlass. The HourGlass code should delay freeing its ECSA storage by the amount of time specified in the parameter.