ADSM-L

Re: Stgpool backup behavior change in 5.3.x?

2005-12-28 12:46:42
Subject: Re: Stgpool backup behavior change in 5.3.x?
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Dec 2005 10:46:32 -0700
        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

<Prev in Thread] Current Thread [Next in Thread>