Description of problem: B.2. Job status codes - This section seems missing explanation and/or the formatting is messed up. I recognize the data and what it means, but there's no context to help the reader figure out what it all means. B.3. Job notification codes - I think this section needs to have its formatting improved. B.4. Shadow exit status codes - Same formatting issues as above. Remove JOB_NOT_CKPTED - We don't support Standard Universe. Also remove mention in JOB_SHOULD_REQUEUE B.5. Job hold reason codes - Same formatting issues GlobusGramError - Remove. We don't support globus Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to comment #0) > Description of problem: > B.2. Job status codes - This section seems missing explanation and/or the > formatting is messed up. I recognize the data and what it means, but there's > no context to help the reader figure out what it all means. This would be because I had no source information to work from. If you can provide some further text around this, then I'll quite happily put it in there. > > B.3. Job notification codes - I think this section needs to have its formatting > improved. > > B.4. Shadow exit status codes - Same formatting issues as above. This section is done as a series of variable lists, the same as the other appendix. I understand that with such short <term> entries, it looks a little odd, though. How would you prefer to handle it? > > Remove JOB_NOT_CKPTED - We don't support Standard Universe. Done Also remove > mention in JOB_SHOULD_REQUEUE <para> <command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the standard universe, and will requeue the job to run it again </para> > > B.5. Job hold reason codes - Same formatting issues See note above. > > GlobusGramError - Remove. We don't support globus Done. LKB
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > B.2. Job status codes - This section seems missing explanation and/or the > > formatting is messed up. I recognize the data and what it means, but there's > > no context to help the reader figure out what it all means. > > This would be because I had no source information to work from. If you can > provide some further text around this, then I'll quite happily put it in there. We already mention and define Universes (5.1.2), I think the formatting here just needs to be cleaned up. It all feels very disjointed. Maybe a table instead of free-form text? For exmaple: 5 Vanilla universe Single process, non-relinked jobs When I read though it, 5 seems disconnected to its explanation. Same issue with B2. I think a table would solve the disjointedness. For B2, I think a 3 column table: # Short Description (used by tools like condor_status) Long Description > > > > B.3. Job notification codes - I think this section needs to have its formatting > > improved. > > > > B.4. Shadow exit status codes - Same formatting issues as above. > > This section is done as a series of variable lists, the same as the other > appendix. I understand that with such short <term> entries, it looks a little > odd, though. How would you prefer to handle it? Tables seem like a clean means to present all the information in these sections. > Also remove > > mention in JOB_SHOULD_REQUEUE > > <para> > <command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the > standard universe, and will requeue the job to run it again > </para> My bad. We don't support standard universe. Suggest changing text to: This exit code implies that we want the job to be put back in the job queue and run again.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > Description of problem: > > > B.2. Job status codes - This section seems missing explanation and/or the > > > formatting is messed up. I recognize the data and what it means, but there's > > > no context to help the reader figure out what it all means. > > > > This would be because I had no source information to work from. If you can > > provide some further text around this, then I'll quite happily put it in there. > > We already mention and define Universes (5.1.2), I think the formatting here > just needs to be cleaned up. It all feels very disjointed. Maybe a table > instead of free-form text? For exmaple: > 5 > Vanilla universe > Single process, non-relinked jobs > > When I read though it, 5 seems disconnected to its explanation. Same issue > with B2. I think a table would solve the disjointedness. > > For B2, I think a 3 column table: > # Short Description (used by tools like condor_status) Long Description > > > > > > > > > B.3. Job notification codes - I think this section needs to have its formatting > > > improved. > > > > > > B.4. Shadow exit status codes - Same formatting issues as above. > > > > This section is done as a series of variable lists, the same as the other > > appendix. I understand that with such short <term> entries, it looks a little > > odd, though. How would you prefer to handle it? > > Tables seem like a clean means to present all the information in these > sections. > Done. > > Also remove > > > mention in JOB_SHOULD_REQUEUE > > > > <para> > > <command>JOB_SHOULD_REQUEUE</command> is used for jobs that are not run in the > > standard universe, and will requeue the job to run it again > > </para> > > My bad. We don't support standard universe. Suggest changing text to: > This exit code implies that we want the job to be put back in the job queue and > run again. <row> <entry> <command>107</command> </entry> <entry> <command>JOB_SHOULD_REQUEUE</command> </entry> <entry> Requeue the job to be run again </entry> </row> LKB