When a job is put on hold, and later released, it will continue where it left off.
It does not start over.
The above is correct. A job will only go to “HLD” status at a point where it can. Generally that means that the machine instruction(s) that are currently being executed will complete before the status actually changes.
That can mean that it may take a long time before it happens. If the MI instruction happens to be a long-running one, it can take time to reach the MI boundary. It would be that boundary where the job starts running from when released.
If a large access path is currently being processed, I’d expect that the entire access path would first finish saving. If there are dependencies, they might all need to be satisfied before status changes. But wherever it happens is where you can expect to re-start from.
Use CPYLIB or other means to create a library to save. Use SBMJOB to run a SAVLIB command. Put *PGMs, *MODULEs, PFs/LFs, multiple source files with lots of members in the library — the more, the better. If you save to savefile, you’re stuck with saving a single library. If you can test saving to a physical device, you might make multiple library copies.
You might have a basic CLP that loops around (or simply repeats) HLDJOB/RLSJOB a few times. Put DLYJOB between each so that you can ensure separated timestamps.
When finished, do DSPOBJD OUTPUT(*OUTFILE) for all libraries/objects in the job. Include the *LIB object(s) as well or simply view them. Note how the ‘Last save’ times compare with joblog messages and the HLDJOB/RLSJOB times.