The first 18 lines are concerned with setting up variables for use during the main loop.

Lines 1-15.  The fifteen first lines simply start the function and set up some variables assigning colours to FCM and VDisk states. These can be changed to suit your needs, with the requirement that all 10 states are present and the colours that are selected are part of the DOT language. Appendix B, Valid colours in the DOT language shows the colours supported by DOT.

Line 16.  This line outputs the first line of DOT, which indicates that we'll be describing a directed graph. We call it F for FlashCopy, but the name is entirely arbitrary (within the constraints of the DOT language)

Line 17.  In this line, we create an array called $possSrcs. This array will be treated as a FIFO stack. It will contain a list of VDisks which are possibly acting as the Sources of an FCM. At this point in the execution, we add the VDisk ID that was provided as the sole parameter to the function. In subsequent passes through the main loop, new VDisk IDs may be added, as required.

Line 18.  Here, we create an empty array which will keep track of all VDisk IDs which have been processed. This is to ensure that the script processes each VDisk ID once and once only.

These lines start the main loop and gather information about the next VDisk ID in the $possSrcs stack.

Line 19.  This starts the main loop of this script. The loop will execute as long as there are VDisk IDs in $possSrcs. This loop ends on line 56.

Lines 20-21.  Lines 20-21 perform the pop operation of a stack, removing the first element from $possSrcs and assigning it to $currSrc.

Lines 22-26.  Lines 22-26 show a technique that will be repeated a number of times in this script. This technique is to run an svcinfo command and execute a series of commands based on each line of output from the svcinfo command.

The technique has the following form:

svcinfo xxxx | while read var1 var2 var3 rest; do
          some commands using $var1, $var2, etc
done

This technique will take each line of output from the svcinfo command and pass it to the read built-in command. The read command works in the following way:

The read command takes a line from STDIN and splits it into words separated according to the Internal Field Separator (IFS). By default, IFS is set to whitespace. The first word is assigned to the first name, the second to the second name and so on. Any leftover words are assigned to the final name with the intervening IFS included.

In the technique shown above, the variables $var1, $var2, etc can now be used by commands inside the while loop. The loop will repeat once per line of output from the svcinfo command. The variable $rest is needed to capture any remaining values at the end of the line of output.

The command svcinfo lsvdisk -nohdr -filtervalue id=$currSrc will generate zero or one line of output. (depending on whether the value in $currSrc is an actual VDisk ID).

Line 24.  This line acts to 'dereference' the VDisk status. The code $(eval echo \$$vStatus) will take the value stored in $vStatus and treat it as the name of a variable and try to find the value stored in that. For instance, if $vStatus is equal to 'preparing' then this line will look for the value found in $preparing and, in this case, return 'yellow'. In this way, we can assign colours to VDisk states.

Line 25.  This generates lines of DOT which define a node in the graph. In this instance a VDisk node is generated. The VDisk node is an ellipse, filled in a colour representing the VDisk's state.

These two lines generate an array of FCM Target VDisk IDs and mark the current VDisk ID (held in $currentSrc) as having been processed.

Lines 27-29.  Lines 27-29 create a new array that holds all of the FCMs which have the current VDisk (represented by $currSrc) as the Source VDisk. This array is called $newTgts. These three lines shows a method of generating an array directly from the output of an svcinfo command. In this particular instance, each line of svcinfo output generates 3 array elements:

where L increases by one per line of svcinfo output.

Line 30.  Line 30 keeps track of the fact that we have now processed the VDisk ID(as an FCM Source... it may appear later as an FCM Target).

These lines process the FCMs that were placed into $newTgts and generate the appropriate DOT to represent them.

Line 31.  Lines 31 creates the loop to process $newTgts. It creates an index variable which is incremented by 3 for each pass (since 3 elements in an array represent one FC Mapping).

Lines 32-35.  Lines 32 to 34 simply collect the relevant array elements in to clearer variable names. Line 35 decodes the FC Mapping status into a colour, much like line 24.

Lines 36-39.  Lines 36-39 generate DOT language; lines 36 and 37 creates an FC Mapping node, which is a square filled with a colour that represents its state.

Lines 38 and 39 generate the edges that link the FC Mapping node with its Source and Target VDisks.

Lines 40-42.  Lines 40-42 look at the FCM Target and determine whether or not it has been processed as a Source. If it has not, it is added to our list of possible Sources: $possSrcs. The code in line 41 acts to place this new VDisk ID at the end of the stack.

Lines 43-45.  Lines 43-45 look to see if there are any dependencies between this FCM and other FCMs. If there are, a new edge is generated to indicate this.

Lines 48-55 perform a similar task to line 27 and the loop that follows it.

Line 48.  Line 48 generates an array of FCM Source VDisk IDs, which have $currentSrc as their Target. This array is called $newSrcs. Instead of generating any DOT in the loop, however, this loop simply adds the indicated VDisk IDs to the $possSrcs array, if they have not previously been processed.

All that remains at this point is to complete the loops, close out the DOT language with a curly bracket and the function is complete.

Adding the makeFCTreeMap function to an interactive session is very straightforward. Simply copy the full text of the script into the clipboard and then paste it into the terminal. Once the script has executed, the makeFCTreeMap function will be available to you for the remainder of that CLI session.

Once you've passed a VDisk ID to the function, you will need to copy the output from the CLI session and place it into a dot file for rendering.

Adding the makeFCTreeMap function to a batch session depends on your SSH client. Here, we will discuss PuTTY for the Windows operating system and ssh for Linux or AIX®.

Whichever operating system you use, the output from the script will be returned to the STDOUT stream on your local system. You can redirect this output to a dot file, and then pass it to your rendering application.

plink -l admin -m script_file -i private_key_file cluster_name
              

ssh -i private_key_file -T admin@cluster_name < script_file