Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 500a098300004060 shows “NetApp-4060-iGrp0-0N” giving suggested nicknames to NetApp Devices.
Just like Apparent VPLEX Patterns, this WWN Descriptor is empirically-based. Additional WWPN samples would help guide a better, more precise solution.
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 50001442607a3b00 shows “VPlex-07a3b-A0-FC00” giving suggested nicknames to EMC VPLEX devices similar to the output of the CLI command ls -l /engine/**/ports.
This WWN Descriptor is not very precise, but is empirically-based. Additional WWPN samples would help guide a better, more precise solution.
Based on some work I was doing with JP “Skwerl” C, I found/remembered/was-embarassed-by Zone-voting ignoring possibilities of duplicate aliases as a default behavior.
This might have been cool before, but it’s out of fashion now. In fact, I find so many customers duping their nicknames, I wonder if there’s some advice on the ‘net suggesting it’s a good practice. Understandably, these are labels being extracted from zone names, so I cannot claim to be the ivory tower of accuracy or best-practice.
Inspection-worthy units have a more difficult time passing combat.
In this revision, I converted ZoneVote to default to allowing dupes; highlights some mismatched assumptions in test cases. see also “Zone Vote is only an approximation” 🙂
Much as I don’t like CSV, I’ve used arrays of strings just as some would use CSVs. If only CSVs were deterministically-parsed… if only spaces didn’t confuse some parsers…
… so in support of butchering text-streams with CSV-like data, and to facilitate the post-processing of content (ie feel like a min/max/avg/deviation/mean+/- 3sigma?), I’ve separated off the RowPrinter content into a separate jar. This allows a basic file to be read, parsers, munged, and ejected back out for others to consume.
A few testcases help to keep me honest.
Tersely, I wrote in the change log:CSVPipe: different chunking and summarizing; ability to set diff keys for chunking; test cases; testsuite.at
In order to allow upstream notification, I’ve added the “–uploadnotify” argument to the FTP uploader:
VICT.BAT -U ftp://scott:tiger@ftp.oracle.com/ --uploadnotify allanc@oracle.com -u logfile1 -u logfile2
Foe each upload, a .sum file would still be generated — in this case, upload1.sum and upload2.sum. The comment “# NOTIFY allanc@oracle.com” is added to the checksum file so that any post-processor knows whom to alert of an upload. If this comment is present and understood, it can be considered advisement, not a directive; default processing may very well occur.
This is not governed by any spec, and I did not find a RFC or other open spec suggesting a format. I’ve suggested using an RFC1738-compatible URL. The format of the checksum file remains compatible with the “sum” and “md5” commands.
Provided a way to generate abbreviated “Suggested Nicknames” (which I call “Estimates” in code, and “SNICK” or “Suggested NICKnames” in PHC).
A customer found that our generated nicknames for missing nicknames was entirely sufficient for his needs, but the names are very long; to make it a bit easier, the VICT will now allow –briefestimate to set for brief suggested nicknames, and –nobriefestimate to counter the setting back to verbose estimates. This is useful when using the -w or –wwn option.
The similar option in PHC is either –briefestimate or –briefsnicks when using the generated phc-Nicknames.csv file.
Switch discovery doesn’t always discover hints to a fabric’s name, and lacking burrowing into the switch in a wholly instrusive and needs-root-access manner, some switches get tossed into “VirtualFabric”. Removing and re-adding switches, I found a user having to re-specify these repeatedly, and forgetting whether it was done.
When I forget things, I get worried. What if someone else does?
…so I added a check in PHC for ProbeSW in Virtual Fabric to catch where the user has not yet named a fabric.
The checksum files sent by an upload really assume that the recipient knows something about checksums. It’s also very difficult to discover what these files are used for lacking the ability to google (whether one arrives at “RFC-1321” or not)
In order to alleviate that assumption, I added some documentation to the actual .sum checksum files provided during an upload. This still requires that a recipient opens the file, but it’s a useful step forward until I can reach through a screen and click the user’s mouse for him.
One part of the Client Tool makes uploads easier if you’re willing to type a commandline; and if you’re not, a batch file is present to reduce that obstacle (but still no GUI).
In order to reduce the doubtful situation of having an upload without confirmation (for example, in cases where an aborted upload looks just like a completed upload: no checksum either way), the upload functionality now sends the checksum before the actual file. I swapped the uploading of the payload file (-u) and the .sum checksum so that the ~.sum file is present before the payload; in truncated/aborted/chopped uploads, this provides a checksum to validate and prove an inaccurate upload rather than assume meaning from a missing .sum file. Aborted/truncated uploads will still fail to validate against the checksum so look the same as any corrupted upload: incorrect. In either case, the reaction is “ask for a re-upload”, so the reaction to a checksum mismatch remains an immediate re-upload.
To avoid recurring errors uploading, I added a convenience script “viupload.bat”; it’s used as follows:
UPLOAD_USER should be set to your usernameUPLOAD_PASS should be set to your password (plaintext, this is for convenience not security)UPLOAD_SUB can remain “ftp” or be set to a region (other regions REM’d out for example)UPLOAD_PATH should be empty or set to a preexisting subdirectory on the server to which uploads should be storedVIUPLOAD PortalLogs.zip HOSTNAME.err backup-2013-09-03-15-02.zip