[prev in list] [next in list] [prev in thread] [next in thread] 

List:       adsm-l
Subject:    Re: Quoting an IBM SP Suite FE capacity based
From:       Del Hoobler <hoobler () US ! IBM ! COM>
Date:       2018-05-03 17:55:42
Message-ID: OFA23214AE.76B84F77-ON85258282.00623081-85258282.00627BAD () notes ! na ! collabserv ! com
[Download RAW message or body]

Hi Tommaso,

This is why the Operations Center FE capacity reporting was introduced.

If you are using the "front-end" model and the Operations Center FE 
capacity reporting isn't sufficient for you, please engage with your IBM 
representative.


Del

----------------------------------------------------
"ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 05/03/2018 
11:57:58 AM:

> From: Tommaso Bollini <T.Bollini@VARGROUP.IT>
> To: ADSM-L@VM.MARIST.EDU
> Date: 05/03/2018 11:58 AM
> Subject: Quoting an IBM SP Suite FE capacity based
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>
> 
> There is something diabolical, and honestly I really do not 
> understand, in the way that IBM indicates to quoting the Spectrum 
> Protect Suite consumer-metric TB/FrontEnd (FE) model.
> IBM spread a manual "IBM Spectrum Protect Suite - FE Licensing 
> Guide", 64 pages(!) in Ver.7.1.6, procedures that almost certainly 
> lead to the execution of Perl or Powershell scripts (based on the sysop)
> data collection utility (dsmfecc - CRT) etc .... and all this to 
> only know the occupation of the active data for one or more nodes.
> Moreover those scripts executes SQL queries to the Spectrum server, 
> widely known as "custodian" of node's data. I think it is more 
> simple to share these SQL SELECT and document that, specifying 
> application field, execution and a matrix of compatibility. Isnt' it?
> Since it is increasingly being leveraged on the OC portal, which is 
> widely advertised reporting, it was no longer appropriate to 
> complete that portal so that there is a single point of
> aggregation and visibility of these occupations?
> 
> Nowadays, given the availability of backup software, given the "zero
> tolerance" average, to any complexity or constriction of constructs,
> still it makes sense to produce such procedures
> so complex, and that let me say, close to madness? (It is 
> unthinkable to run scripts on farms made of hundreds or thousands of
> nodes with different types or login credentials!)
> Why this? Why is the FE data in most of our installations the most 
> convenient for a quotation?
> I believe that the future of this product is still in waters made of
> complexity and difficulty in management and...Error is only human, 
> but to persist in it, is diabolical!
> Sorry for my poor english. Here speak a disappointed SP (TSM) fan.
> 
> 
> ________________________________________________________
> Tommaso Bollini
> Spectrum Protect Specialist
> 
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic