2 Intern

 • 

292 Posts

March 9th, 2010 08:00

Looking at the SR, looks like your questions were answered?  For the rest, this was the recommendation:

From ECC you may view the Meta and its members in a graphical format,

Select Relationship from ECC console.
Expand Symmetrix from Storage Systems and select Meta Devices.

This would show the Meta Head, Meta Members and Back-End devices and the FA it is mapped to.

You may export this in an html format.

For backend, select the device and look under the properties which displays the meta members and the backend devices.  For viewing submembers, select relationships and then storage device.

52 Posts

March 9th, 2010 08:00

The graphical format is NOT what i am looking for.. that i know about that, but that means i have to type out a few thousand different devices.

I personally found a work-around solution of right clicking on the DMX array, going to relationships, and than selecting Storage Devices.

This gives me the Devices and sub-Devices in a workable format, but not exactly what i'm looking for.  To get what i'm looking for we're combing about 3 different tables together after we massage the tables to have the same consitant columns.

So a worak-around is found (by me) but this is not solved.

There has to be an easier way to get this information output as 1 table.  Yes, the relationship view has the information i am looking for, but you can't export it as an excel sheet & you can't view all 500+ Metas on our array with it.

All i want, is a that data from the relationships view in a spreadsheet.  I was hoping there could be some Solutions Enabler command to pull that information directly from the VCMDB.

9 Posts

March 9th, 2010 10:00

If you have access to an XSLT processor, this should do the trick.  (I run this on a Unix-based system but it's do-able on Windows as well).

$ symdev -sid 0123 -v list -output xml_element >symdev.0123.xml

$ xsltproc metainfo.xsl symdev.0123.xml

*** metainfo.xsl ***


http://www.w3.org/1999/XSL/Transform ">


       

          
            

          
            

          
            


       



*** EOF ***

Note there are tab characters (which don't cut/paste too well) to generate a tab-separated file.

The resulting output looks like this:

00D4    00D4    Head
00D5    00D4    Member
00D6    00D4    Member
00D7    00D7    Head
00D8    00D7    Member
00D9    00D7    Member
00DA    00D7    Member
00DB    00D7    Member
00DC    00D7    Member
00DD    00D7    Member
00DE    00D7    Member
00DF    00D7    Member
0100    0100    Head
0101    0100    Member
0102    0100    Member
0103    0100    Member
0104    0104    Head
0105    0104    Member
0106    0104    Member
0107    0104    Member
0162    0162    Head
0163    0162    Member
0164    0162    Member
0165    0162    Member
0166    0162    Member
0167    0162    Member
0168    0162    Member
0169    0162    Member
016A    0162    Member
016B    0162    Member
016C    0162    Member
016D    0162    Member
016E    0162    Member
016F    016F    Head
0170    016F    Member
0171    016F    Member
0172    016F    Member
0173    016F    Member
0174    016F    Member
0175    016F    Member
0176    016F    Member
0177    016F    Member
0178    016F    Member
0179    016F    Member
017A    016F    Member
017B    016F    Member

Hope this helps.

52 Posts

March 9th, 2010 13:00

that would be perfect... i'll have to look a lil deeper to try it, but will try it.

53 Posts

March 10th, 2010 06:00

I've recently started using perl, and XML::Twig to parse SYMAPI XML.

Er.

Something like:

use strict;
use warnings;

use XML::Twig;

sub device_handler
{
  my ( $twig, $device ) = @_;

  unless ( $device -> first_child('Flags') -> first_child('meta') -> text =~ m/None/ )
  {
    my $dev = $device -> first_child('Dev_Info') -> first_child('dev_name') -> text;
    my $meta_head = $device -> first_child('Meta') -> first_child('Meta_Device') -> first_child('dev_name') -> text;
    print "$meta_head,$dev\n";
  }
  $twig -> purge;
}


# dump XML
my $twig = new XML::Twig (
           twig_handlers =>
                   { 'Device' => \&device_handler } );

print "Running symcfg discover...\n";
print `symcfg discover`;
print "Dumping symdev list to temporary file 'symdev_list_v.xml'\n";
print `symdev list -v -output XML > symdev_list_v.xml`;
$twig -> parsefile ( "symdev_list_v.xml" );
  

Will work on both Unix and Windows, but with Windows/Activestate perl, you'll need to download and install XML::Twig yourself.
It writes out a file, rather than just running in memory because 'symdev list -output XML' gets pretty big - and XML parsing can take a lot of memory, so I work through it sequentially.

9 Posts

March 16th, 2010 20:00

Ed_R,  Interesting piece of code...

An interesting example of the trade-off between space and time.  You are definitely correct about XSLT being memory hungry.  A 70 MB symdev XML output file will consume 600MB (or more) of memory processed through Xalan.   I ran your Perl script against athe same file.  Very memory efficient (about 10MB), but it took almost 10 minutes to run.  Xalan takes less than 90 seconds.

That being said... nice to see other ways of skinning the proverbial cat.

No Events found!

Top