I recently upgraded from 5.2.mumble to 5.3.2.1; In the intervening weeks, I've
noticed a behavior change which I don't see addressed in the change notes.
I'm hoping for corroboration, and perhaps a comment from one of our onlooking
developers.
In 5.2, my user interaction looked like this:
1) Run BACKUP STGPOOL primpool copypool
2) New process appears in process listing
3) prompt returns
4) process looks for uncopied data, has status numbers of 0 files, 0 bytes
until it finds some. It might never find any, in which case it reports
success, with 0 files, 0 bytes as additional information.
In 5.3, the following happens
1) Run BACKUP STGPOOL primpool copypool
2) prompt does not return
3) a process starts, not reflected in the process listing, and looks for
uncopied data.
4) if the process finds uncopied data, THEN:
4a) The prompt returns
4b) a process appears in the process listing, life goes on as before.
5) if the process does not find uncopied data THEN:
5a) The prompt returns with a ANR2111W, 'no data to process'.
5b) no process appears
I Can tell that 3) happens, because if I try to run another backup stgpool, I
get the conventional 'backup already in progress' message. But it's not
reflected in the process table. I have several servers which take >8hrs to
run a good stgpool backup, even if they do no new copying work. That's a long
time to have something going on behind the scenes.
This block-the-command-flow behavior is really disruptive; the process once
started is declared as 'background', and WAIT still defaults to no. But this
is definitely a foreground process.
So: Do you-all share my impression here, and any IBMers want to comment?
- Allen S. Rout
|