Hi, Am 29.02.2012 um 03:31 schrieb Kevin Buckley:
> was recently trying to get some info from the XML output from a "qstat -j" and > noticed that for two running jobs, the s_rt value that had been supplied in > two > different ways, appeared within two different "XPaths" > > A job that had supplied the s_rt limit as a submission request sees > the XML place the > value at a "path" identifiable as > > <detailed_job_info><djob_info><element><JB_hard_resource_list><qstat_l_requests><CE_name>s_rt > > whereas a job which had had the s_rt limit added in, via a qalter > whilst still in the queue, saw it turn up as > > <detailed_job_info><djob_info><element><JB_hard_resource_list><element>CE_name>s_rt > > I can see why the two would be different (because they are!) but, once > I had discovered > that there were two paths to the "same info", wondered if, once a job > was running and > so limits such as s_rt had become immutable, they would be better > represented by the > second form, ALONG with the first, if values had been specified that way. > > Do the internal structures of the GE code maintain both "submitted" > and "allocated" values, > so that this might be possible ? I would say no. There are some traces in the sources that it might be available later, but for now these are dummy entries: handler->job_handler.report_soft_resources_started = qstat_xml_dummy_started; handler->job_handler.report_soft_resource = qstat_xml_job_soft_resource; handler->job_handler.report_soft_resources_finished = qstat_xml_dummy_finished; It's of course interesting, that by changing the request the name in the XML output changes. In the normal `qstat -j <job_id>` output an additional entry "version:" will reflect that there was a change. The accouting file only records the last known values too. If you want to have a way to check the original values: a JSV could copy the original supplied values into a job context (-ac ...). I don't know, whether this would be suitable for you, as the user could also change the values in the job context. And after the job the job context is gone too. === I use the job context to store some other stuff, and send it with the usual job email to the user by extending it in a email-wrapper. You could output in the email both: job context values (supposing they werent changed), and the last known values. Please let me know if you want to use it, as there are some pitfalls to note (mainly: the email is set after the job left the node already). -- Reuti > Kevin Buckley > ECS, VUW, NZ. > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
