I wound up using Alex Paschal's method - thanks!

I am not worried (yet!) about damaged files. There are probably very few
of them anyway. I am only doing a FIX=NO audit to see where the problems
are. I'm capturing the results by Q ACTLOG ... SEARCH='PROCESS: 9999'
and parsing msg ANR4133I for the audit results. If FIX=NO does not find
any damaged files, as reported in ANR4133I, then the disk file volume is
changed to READWRITE automatically. If the FIX=NO audit does find
something wrong, then I will deal with it manually and carefully.

I did not want to use Eric van Loon's suggestion of MOVE DATA, because
that would really fill up this storage pool, considering we use a reuse
delay. The advantage of AUDIT is that it does not cause any data
movement other than one read pass, and most of the volumes will not have
any problems.

Thanks again, to both Eric and Alex. That was the obvious solution - a
sleep loop querying processes after starting the AUDIT command. The
improvement I added was to get the actual results via Q ACTLOG after it
was finished.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Tue, 6 Nov 2012, Alex Paschal wrote:

>Hi, Roger.  I don't have one already made, but this should get you
>started.  Hopefully there won't be too many typos.
>
>#!/usr/bin/ksh
>dsmadmc -id=id -pa=pa audit vol /path/file1
>sleep 10
>while dsmadmc -id=id -pa=pa -comma q pr | grep -qi audit ; do
>    sleep 10
>done
>dsmadmc -id=id -pa=pa update vol /path/file1 acc=readw
>
>On 11/6/2012 3:17 PM, Roger Deschner wrote:
>> Does anybody have a script or program that can issue a TSM AUDIT VOLUME
>> command and wait for it to finish - as though WAIT=YES existed?
>>
>> I keep getting r/o vols in my DEVCLASS FILE storage pools. I want to
>> audit them before changing them back to r/w. I want an automatic process
>> to do that, one at a time.
>>
>> I could have set up this storage pool with preallocated files instead of
>> letting the operating system allocate and remove scratch volume files,
>> but dsmfmt on 55TB of space to prepare the fixed volume files would take
>> a very long time, like about a CPU-year.
>>
>> Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT 
>> edu
>> ======I have not lost my mind -- it is backed up on tape somewhere.=====
>>
>