When you are sharing an online database with batch update jobs you don’t want batch jobs to affect online response time. One thing that invariably delays online transactions are batch database locks. If the batch job doesn’t take enough syncpoints, more and more of the database will be locked as the job runs. The best you could do is take a syncpoint after every record processed but that incurs far too much overhead. One way would be for the batch job to count the records and take syncpoints after some arbitrary number of records or database calls or even score the database calls based upon their perceived effect and take syncpoints after an arbitrary score is reached. But these methods don’t adjust to CPU upgrades, tape mounts, etc.
Wouldn’t it be better to decide ahead of time the maximum delay to an online transaction you are willing to allow and ensure the batch job doesn’t exceed that amount of time? Say, five seconds or so?
What we did is write an Assembler subroutine that uses the STIMERM service to set a time. When the time expires (the set time interval elapses) the an exit set up by the subroutine runs and sets a specified flag in the calling program’s working-storage. The Calling program then just need to check the flag to see if it is “time” for a syncpoint.
- set a timer for the necessary number of seconds (0.1 & above)
- do an item of work
- if it is time for a synpoint (the flag has been set):
- take a syncpoint
- set a new timer
- Loop back to (2.) until work is done
- cancel existing timer
Some syntax information:
77 timer-id pic x(04). 77 interval pic s9(6)v99 comp. 77 flag pic x(01). 88 flag-not-set value 'N'. 88 flag-set value 'Y'. [...] move +5.00 to interval call 'TIMERPOP' using 'INTERVAL' timer-id interval flag [...] call 'TIMERPOP' using 'CANCEL' timer-id
At first I was timid about giving this to developers to use since I wasn’t sure about the timer exit getting control properly or that it might cause overlays or 0C4 abends. But, it seems to work pretty well at least for COBOL callers. The only problem we ran into was with programs that did not cancel the timer before GOBACK. It is possible to get an 0C4 then because the timer may still be active after the calling program ends but before the TCB has completed.