xcu_chap03.html

IEEE 1003.1-2003, Single Unix Specification v3

future.</p>

<p>The addition of <i>network</i> as a defined term was done to clarify the difference between a network of batch nodes as opposed
to a network of hosts. A network of batch nodes is referred to as a batch system. The network refers to the actual host
configuration. A single host may have multiple batch nodes.</p>

<p>In the absence of a standard network naming convention, this option establishes its own convention for the sake of consistency
and expediency. This is subject to change, should a future working group develop a standard naming convention for network
pathnames.</p>

<h4><a name="tag_02_03_01"></a>Batch General Concepts</h4>

<p>During the development of the Batch Environment Services and Utilities option, a number of topics were discussed at length which
influenced the wording of the normative text but could not be included in the final text. The following items are some of the most
significant terms and concepts of those discussed:</p>

<ul>
<li>
<p>Small and Consistent Command Set</p>

<p>Often, conventional utilities from UNIX systems have a very complicated utility syntax and usage. This can often result in
confusion and errors when trying to use them. The Batch Environment Services and Utilities option utility set, on the other hand,
has been paired to a small set of robust utilities with an orthogonal calling sequence.</p>
</li>

<li>
<p>Checkpoint/Restart</p>

<p>This feature permits an already executing process to checkpoint or save its contents. Some implementations permit this at both
the batch utility level (for example, checkpointing this job upon its abnormal termination) or from within the job itself via a
system call. Support of checkpoint/restart is optional. A conscious, careful effort was made to make the <a href=
"../utilities/qsub.html"><i>qsub</i></a> utility consistently refer to checkpoint/restart as optional functionality.</p>
</li>

<li>
<p>Rerunability</p>

<p>When a user submits a job for batch processing, they can designate it &quot;rerunnable&quot; in that it will automatically resume
execution from the start of the job if the machine on which it was executing crashes for some reason. The decision on whether the
job will be rerun or not is entirely up to the submitter of the job and no decisions will be made within the batch system. A job
that is rerunnable and has been submitted with the proper checkpoint/restart switch will first be checkpointed and execution begun
from that point. Furthermore, use of the implementation-defined checkpoint/restart feature will not be defined in this context.</p>
</li>

<li>
<p>Error Codes</p>

<p>All utilities exit with error status zero (0) if successful, one (1) if a user error occurred, and two (2) for an internal Batch
Environment Services and Utilities option error.</p>
</li>

<li>
<p>Level of Portability</p>

<p>Portability is specified at both the user, operator, and administrator levels. A conforming batch implementation prevents
identical functionality and behavior at all these levels. Additionally, portable batch shell scripts with embedded Batch
Environment Services and Utilities option utilities add an additional level of portability.</p>
</li>

<li>
<p>Resource Specification</p>

<p>A small set of globally understood resources, such as memory and CPU time, is specified. All conforming batch implementations
are able to process them in a manner consistent with the yet-to-be-developed resource management model. Resources not in this
amendment set are ignored and passed along as part of the argument stream of the utility.</p>
</li>

<li>
<p>Queue Position</p>

<p>Queue position is the place a job occupies in a queue. It is dependent on a variety of factors such as submission time and
priority. Since priority may be affected by the implementation of fair share scheduling, the definition of queue position is
implementation-defined.</p>
</li>

<li>
<p>Queue ID</p>

<p>A numerical queue ID is an external requirement for purposes of accounting. The identification number was chosen over queue name
for processing convenience.</p>
</li>

<li>
<p>Job ID</p>

<p>A common notion of &quot;jobs&quot; is a collection of processes whose process group cannot be altered and is used for resource
management and accounting. This concept is implementation-defined and, as such, has been omitted from the batch amendment.</p>
</li>

<li>
<p>Bytes <i>versus</i> Words</p>

<p>Except for one case, bytes are used as the standard unit for memory size. Furthermore, the definition of a word varies from
machine to machine. Therefore, bytes will be the default unit of memory size.</p>
</li>

<li>
<p>Regular Expressions</p>

<p>The standard definition of regular expressions is much too broad to be used in the batch utility syntax. All that is needed is a
simple concept of &quot;all''; for example, delete all my jobs from the named queue. For this reason, regular expressions have been
eliminated from the batch amendment.</p>
</li>

<li>
<p>Display Privacy</p>

<p>How much data should be displayed locally through functions? Local policy dictates the amount of privacy. Library functions must
be used to create and enforce local policy. Network and local <a href="../utilities/qstat.html"><i>qstat</i></a>s must reflect the
policy of the server machine.</p>
</li>

<li>
<p>Remote Host Naming Convention</p>

<p>It was decided that host names would be a maximum of 255 characters in length, with at most 15 characters being shown in
displays. The 255 character limit was chosen because it is consistent with BSD. The 15-character limit was an arbitrary
decision.</p>
</li>

<li>
<p>Network Administration</p>

<p>Network administration is important, but is outside the scope of the batch amendment. Network administration could be done with
<i>rsh</i>. However, authentication becomes two-sided.</p>
</li>

<li>
<p>Network Administration Philosophy</p>

<p>Keep it simple. Centralized management should be possible. For example, Los Alamos needs a dumb set of CPUs to be managed by a
central system <i>versus</i> several independently-managed systems as is the general case for the Batch Environment Services and
Utilities option.</p>
</li>

<li>
<p>Operator Utility Defaults (that is, Default Host, User, Account, and so on)</p>

<p>It was decided that usability would override orthogonality and syntactic consistency.</p>
</li>

<li>
<p>The Batch System Manager and Operator Distinction</p>

<p>The distinction between manager and operator is that operators can only control the flow of jobs. A manager can alter the batch
system configuration in addition to job flow. POSIX makes a distinction between user and system administrator but goes no further.
The concepts of manager and operator privileges fall under local policy. The distinction between manager and operator is historical
in batch environments, and the Batch Environment Services and Utilities option has continued that distinction.</p>
</li>

<li>
<p>The Batch System Administrator</p>

<p>An administrator is equivalent to a batch system manager.</p>
</li>
</ul>

<h4><a name="tag_02_03_02"></a>Batch Services</h4>

<p>This rationale is provided as informative rather than normative text, to avoid placing requirements on implementors regarding
the use of symbolic constants, but at the same time to give implementors a preferred practice for assigning values to these
constants to promote interoperability.</p>

<p>The <i>Checkpoint</i> and <i>Minimum_Cpu_Interval</i> attributes induce a variety of behavior depending upon their values. Some
jobs cannot or should not be checkpointed. Other users will simply need to ensure job continuation across planned downtimes; for
example, scheduled preventive maintenance. For users consuming expensive resources, or for jobs that run longer than the mean time
between failures, however, periodic checkpointing may be essential. However, system administrators must be able to set minimum
checkpoint intervals on a queue-by-queue basis to guard against, for example, naive users specifying interval values too small on
memory-intensive jobs. Otherwise, system overhead would adversely affect performance.</p>

<p>The use of symbolic constants, such as NO_CHECKPOINT, was introduced to lend a degree of formalism and portability to this
option.</p>

<p>Support for checkpointing is optional for servers. However, clients must provide for the <b>-c</b> option, since in a
distributed environment the job may run on a server that does provide such support, even if the host of the client does not support
the checkpoint feature.</p>

<p>If the user does not specify the <b>-c</b> option, the default action is left unspecified by this option. Some implementations
may wish to do checkpointing by default; others may wish to checkpoint only under an explicit request from the user.</p>

<p>The <i>Priority</i> attribute has been made non-optional. All clients already had been required to support the <b>-p</b> option.
The concept of prioritization is common in historical implementations. The default priority is left to the server to establish.</p>

<p>The <i>Hold_Types</i> attribute has been modified to allow for implementation-defined hold types to be passed to a batch
server.</p>

<p>It was the intent of the IEEE P1003.15 working group to mandate the support for the <i>Resource_List</i> attribute in this
option by referring to another amendment, specifically the IEEE&nbsp;P1003.1a draft standard. However, during the development of
the IEEE&nbsp;P1003.1a draft standard this was excluded. As such this requirement has been removed from the normative text.</p>

<p>The <i>Shell_Path</i> attribute has been modified to accept a list of shell paths that are associated with a host. The name of
the attribute has been changed to <i>Shell_Path_List</i>.</p>

<h4><a name="tag_02_03_03"></a>Common Behavior for Batch Environment Utilities</h4>

<p>This section was defined to meet the goal of a &quot;Small and Consistent Command Set&quot; for this option.</p>


<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; is a registered Trademark of The IEEE.<br>
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
]</font></center>

<!--footer end-->
<hr size="2" noshade>
</body>
</html>