Monthly Archives: September 2013

Revision 592 – CSVPipe Separated

Posted on by

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

Revision 590 – Added –UploadNotify as a Checksum Comment

Posted on by

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.

Revision 587 – Abbreviate the Suggested Nicknames (SNICKs) in PHC

Posted on by

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.

Revision 586 – UnAssigned Switches

Posted on by

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.

Revision 584 – User-Documentation in .sum Files

Posted on by

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.

Revision 582 – Swapped .sum Checksum File to be Available Before the Upload

Posted on by

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.