We too have seen this issue and I agree, it's annoying. It
behaves kinda like you put the "wait=yes" option on the command so that
it will not return the prompt until the command completes.
One of our foreign sites opened up a case with Tivoli about it,
but I have not heard what the outcome is. I will let you know if they
find anything out.
Since we are still at 5.2, I haven't had to battle that problem yet at
my location.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Allen S. Rout
Sent: Wednesday, December 28, 2005 9:56 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Stgpool backup behavior change in 5.3.x?
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
|