> Not so sure about the format, though - the one above is hard to read, and I
> would claim it might be prone to produce errors on all parties involved - e.g.
> whenever we add further fields. Something that correlates the values to a
> field
> name is preferable - maybe something like JSON could do the job here!
Which was kind of the point of the comment; most of the things that will
consume the output of the command are not human, so readability isn't a concern
unless you request the extra icing of human-readable output via --verbose.
Parsing simplicity is the paramount concern here.
I'm not a huge fan of JSON, but I can see that it would be a useful method;
might also consider XML as well. The semantics of both XML and JSON processing
would be expensive to generate (lots of wrapping/unwrapping involved).
Awk-friendly is good. __
> One could always do that by post-processing the output. Also, this would need
> some semantics: We should likely count virtalization layers, not levels.
> Because
> e.g. z/VM can or can not have a Resource Pool defined. As one does not know in
> advance, it should not be counted. But then again, that makes it a bit more
> complicated. I'd likely push that out as a future item.
Fair enough, was just an idea of some useful function. Since you have a record
type field available, I had envisioned it as a kind of variant record that you
parsed depending on what the record type is. If you keep the record type in
each line of the output, expansion for new values wouldn't be a big deal.
> Something like that is already available in the underlying library, although
> it
> counts levels/layers, not _virtualization_ levels. Makes sense to keep it
> that way.
Ok. Since I can't see the capability of the code you've got to play with, that
seems to be a good place to start.
> There's a field like that available, but not in every layer. However, this is
> really easy to derive from the output, so not sure if I'd want to add it...
Yeah, there's always that argument of what combinations of features merit
packaging as a command-line option as a shortcut. I would find that number
useful as a "feature", YMMV.
> 6. (nit) in the verbose output, provide a way to provide a format string
option, eg:
>
> ./qc_test --verbose --format="30:8.3"
>
> qc_capability [S ] : 552.000
> qc_secondary_capability [S ] : 552.000
> qc_capacity_adjustment_indication [S ]: 100.000
> qc_capacity_change_reason [S ] : 0.000
> Uh, yeah, well, another 'future' I would say.
Yeah, ok. There are some libraries in the GNU world that provide this kind of
function generically, but agree that it doesn't need to be there day 1. The
idea was to make the output more useful/easier to parse in languages that have
fixed format input records (eg COBOL or PL/1), but no matter. Works for me.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
