ADSM-L

Stgpool backup behavior change in 5.3.x?

2005-12-28 11:55:46
Subject: Stgpool backup behavior change in 5.3.x?
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Dec 2005 11:55:40 -0500
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>