Getting jobquery to talk to you

I’ve been using nsradmin for the last 12 years. So when I read about a new utility, ‘jobquery’ in NetWorker 7.5, that’s designed to work in a similar way to nsradmin but query the jobs database instead of the media database, I was looking forward to giving it a go. (This was in no small part to lingering disappointment over how nsrjobsd has been practically a black box since it was introduced.)

So I was rather … disappointed when I ran jobquery for the first time and it appeared to hang.

Running, say:

# jobquery

Appeared to hang.

Running, say:

# jobquery -s server

Also appeared to hang.

Running, say:

# jobquery -s server print

Didn’t return a thing.

So I thought maybe this is a tool that was let out of the barn a little too soon, and even went to the point of logging a question case with EMC about it. After all, it appeared to not really work at all.

It turns out I’d not anticipated that there might have been a simpler problem with jobquery, that being … less than desirable interface design. Let’s be blunt: if you write an interactive “shell” style query interface, it should tell the user when it’s waiting for input.

The problem with the initial invocation attempts was a simple one – it wasn’t hanging, but instead, it was waiting for input without telling me it was waiting for input. Consequently, I’m currently asking EMC to file a bug about this. I know the difference between RFEs and bugs – an RFE is a request for enhancement, or to change something that’s there by design, but a bug is a problem with the actual implementation. Now, someone might argue that maybe this should be filed as an RFE if it was originally designed to not show any prompt, but my take on it is that any interface that doesn’t differentiate between “waiting for input” and “processing/stuck” is, in actuality, a buggy design.

Oh, and jobquery just doesn’t like being told what to do in relation to queries on the command line, even though the man page says it will accept it.

If you’ve been trying to use jobquery and not getting much satisfaction, try it again without waiting for a prompt. Once I got past the lack of prompt, I was quite excited by the promise of jobquery – in fact, I’m hoping that a future release will actually implement the ability to even stop jobs – e.g., kill off a single saveset, or even say, pause a clone/stage operation.

No doubt jobquery needs some improvements, but it wasn’t quite the aborted attempt I’d been initially worried about, and you should give it a go – you’ll be pleasantly surprised.