[gpfsug-discuss] mmbackup monitoring

[Jonathan Buzzard]

On 25/03/2020 14:15, Skylar Thompson wrote:
> We execute mmbackup via a regular TSM client schedule with an incremental
> action, with a virtualmountpoint set to an empty, local "canary" directory.
> mmbackup runs as a preschedule command, and the client -domain parameter is
> set only to backup the canary directory. dsmc will backup the canary
> directory as a filespace only if mmbackup succeeds (exits with 0). We can
> then monitor the canary and infer the status of the associated GPFS
> filespace or fileset.
> 

I prefer this approach I think than grovelling around in log files that 
could easily break on an update. Though there is a better approach which 
in my view IBM should be using already in mmbackup.

It came to me this afternoon that one could use the TSM API for this. 
After a bit of Googling I find there is an API call dsmUpdateFS, which 
allows you to update the filespace information on the TSM server.

Fields that you can update include

DSM_FSUPD_OCCUPANCY
DSM_FSUPD_CAPACITY
DSM_FSUPD_BACKSTARTDATE
DSM_FSUPD_BACKCOMPLETEDATE

Information on the API call here

https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.9/api/r_cmd_dsmupdatefs.html

How do we submit this as a feature request again? That said in my view 
it's a bug in mmbackup. The latest in a very long line stretching back 
well over a decade that make mmbackup less than production ready rather 
than a feature request :-)

I feel a breakout of a text editor and some C code coming on in the 
meantime.


JAB.

-- 
Jonathan A. Buzzard                         Tel: +44141-5483420
HPC System Administrator, ARCHIE-WeSt.
University of Strathclyde, John Anderson Building, Glasgow. G4 0NG