Tom, What you point out is important to many sites.
Last April the then Chief architect of ADSM (Paul Bradshaw) attended a
European ADSM Workshop at Karlsruhe. At that time I made a presentation
point about collecting and analysing adsm performance data. One of the
things I highlighted was the many inconsistencies of process start and end
and the recording (or very often the lack of recording) of exactly what work
a process did.
Another example of a process that is difficult to track is MOVE DATA - that
doesn't report who it is when starting in terms of process id, nor when it
ends.
Only the "newer" processes/commands like BACKUP STORAGE actually tell you
how many files/how much data they have moved.
Some processes tell the command line they have started (like BACKUP DB) but
others that e.g. are triggered by "update stg xxx hi=0 lo=0" don't and you
have to hunt in the activity log. The only reliabel way I have found to
track a migration task ending (there may be many processes both in parallel
and in a sequence) is to loop around doing 'q stg xxxx f=d" and look for
"migration in progress: no". Then I can also record how much data the
migration task has achieved.
All processes should say who they are and what they have done at start and
end.
It all makes life very difficult - not just for performance measurement but
for sanity in automating the management of a large adsm system. I thought
at the time that Paul took on board my pleas (- which are needed by many
more than me) but, as yet, I have had no feedback as to whether any process/
messsage/consistency enhancements will make it into V3 of adsm server.
Paul has now left IBM so is probably not able to answer whether there is any
hope at V3 (are you listening Paul?). I'm an optimistic sort of person ...
I know there are lots of other goodies to come in V3 but it would be nice to
know about these points from someone who is in a position to know, please.
Thanks.
Best wishes, Sheelagh
------------------------------------------------------------------------------
Sheelagh Treweek Email: sheelagh.treweek AT oucs.ox.ac
DOT uk
Sheelagh Treweek Email: sheelagh.treweek AT oucs.ox.ac
DOT uk
Oxford University Computing Services Tel: +44 (0)1865 273205
13 Banbury Road, Oxford, OX2 6NN, UK Fax: +44 (0)1865 273275
------------------------------------------------------------------------------
> From owner-adsm-l AT VM.MARIST DOT EDU Thu Jul 17 16:16:23 1997
> From owner-adsm-l AT VM.MARIST DOT EDU Thu Jul 17 16:16:23 1997
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Date: Thu, 17 Jul 1997 11:14:31 -0400
> From: Tom Denier <tom AT STAFF.UDC.UPENN DOT EDU>
> Subject: Background process monitoring
> To: ADSM-L AT VM.MARIST DOT EDU
>
> Like a number of other subscribers to this list, I have a need to run a
> series of ADSM server commands in succession, with some of the commands
> starting background processess. I wrote a script to handle the general
> problem of executing a command that starts a background process and
> waiting for the background process to start. When I first did this
> I discovered that all of the commands I was interested in generated
> ANR messages that ended 'started as process nnn.' I wrote a somewhat
> convaluted awk script to extract process numbers from such messages.
>
> I recently decided to add 'expire inventory' to the set of commands
> executed sequentially. I checked my activity log and discovered that
> previous 'expire inventory' commands had generated ANR messages ending
> with 'started as process nnn.' I confidently set up my general purpose
> script to run 'expire inventory' and wait for the resulting background
> process to complete. The script reported that the background process
> had failed to start. I eventually used an UNIX tee command to write
> the output of the dsmadmc command to a file, and discovered that the
> message ending in 'started as process nnn.' was not included in the
> output from dsmadmc. However, I discovered the following ANS message
> in the dsmadmc output: 'ANS5104I Process number nnn started.' I
> changed my script to take advantage of this message. The next time
> I attempted to run the sequence of ADSM commands my script reported
> that the background process for 'backup db' had failed to start. It
> turns out that dsmadmc does not produce an ANS5104 message when used
> to execute a 'backup db' command, but does produce such a message
> when used to execute a 'backup stgpool' or 'expire inventory' command.
>
> It would seem that the ADSM developers have introduced not one but
> two totally gratuitous inconsistencies in the treatment of messages
> reporting the starting of background processes, and that the combined
> effect of the two inconsistencies is to preclude any uniform approach
> to capturing the background process number.
>
> I don't think there is any real possibility of getting this fixed
> through the APAR process. I have not been able to find any documentation
> explaining in detail how background process start-up is supposed to
> work. This shields the developers from complaints that background
> process start-up is not working the way it is supposed to. Do I have
> any other recourse?
|
