[GE users] qstat -j -xml output information

Olesen, Mark Mark.Olesen at emcontechnologies.com
Wed May 7 08:05:00 BST 2008

> thanks for the reply and the useful suggestions. I still have one
> important question based on your requirements though, and I think it
> is
> important to clarify this before I continue.
> In your response, you wrote that "Extra data is fine but making
> "qstat"
> and "qstat -xml" report the same data should be a priority."
> Does this "Extra data" mean that "qstat -xml" can have more
> information
> that the "qstat" output, or do you require that all the output in
> "qstat
> -xml" is shown in "qstat" and vice versa?
> Thanks for the clarification,

Hi Michael,

I'll jump in for Chris (and others). I don't see a problem with having
*more* information reported in the "-xml" output than is reported in the
non-xml version. But it is really bad when information available in the
non-xml output is missing from the "-xml" output.

I think the following is reasonable:
1. Freeze the current non-xml output as is. We can call it 'legacy'
output it that sounds nicer.
2. Ensure that everything available in the legacy output is also
available in the xml output.
3. Add extra information (submissionTime, queue master, etc) into the
xml output without worrying about updating the legacy output (for now,
or maybe at all).
4. Rationalize the xml output (see my posting on the dev list:
5. Consider adding some form of query mechanism for retrieving the only
specific parts of the output.

To explain points 4 & 5 more closely: Suppose I am quickly trying to
find the original working directory for all the jobs. With the legacy
output I could use something like this:
   qstat -j \* | sed -ne 's/^\(job_number\|sge_o_workdir\): *//p'

To extract something similar from the xml output without using a full
blown XSLT engine is considerably more difficult. Not impossible, but
quite difficult. The first thing that would ease the task would be an
xml output that is structured with a view to the user instead of being
more or less a dump of the internal cull list.
Assuming that many people have faced with a similar problem - parsing
massive xml output and extracting particular bits of information - why
not invert the problem? If the user could simply query the bits of
information required, a large amount of repetitive parsing could be
eliminated. It should also help reduce bandwidth between client and
qmaster. The "ps -o ..." interface could be a suitable model as could
some XPath type of query.

I realize that these last two points are beyond the scope of the current
discussion, but nonetheless worth mentioning (I hope).


This e-mail message and any attachments may contain 
legally privileged, confidential or proprietary Information, 
or information otherwise protected by law of EMCON 
Technologies, its affiliates, or third parties. This notice 
serves as marking of its ?Confidential? status as defined 
in any confidentiality agreements concerning the sender 
and recipient. If you are not the intended recipient(s), 
or the employee or agent responsible for delivery of this 
message to the intended recipient(s), you are hereby 
notified that any dissemination, distribution or copying 
of this e-mail message is strictly prohibited. 
If you have received this message in error, please 
immediately notify the sender and delete this e-mail 
message from your computer.

To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list