port.html

IEEE 1003.1-2003, Single Unix Specification v3

<dd>
The system supports the FORTRAN Development Utilities option 

<p>As with C, this option is needed on any system developing or installing FORTRAN applications in source form.</p>
</dd>

<dt>POSIX2_FORT_RUN</dt>

<dd>
The system supports the FORTRAN Runtime Utilities option. 

<p>This option is required for some FORTRAN applications that need the <a href="../utilities/asa.html"><i>asa</i></a> utility to
convert Hollerith printing statement output. It is unknown how frequently this occurs.</p>
</dd>

<dt>POSIX2_LOCALEDEF</dt>

<dd>
The system supports the creation of locales. 

<p>This option is needed if applications require their own customized locale definitions to operate. It is presently unknown
whether many applications are dependent on this. However, the option is virtually mandatory for systems in which internationalized
applications are developed.</p>

<p>XSI-conformant systems support this option.</p>
</dd>

<dt>POSIX2_PBS</dt>

<dd>
The system supports the Batch Environment Services and Utilities option.</dd>

<dt>POSIX2_PBS_ACCOUNTING</dt>

<dd>
The system supports the optional feature of accounting within the Batch Environment Services and Utilities option. It will be
required in servers that implement the optional feature of accounting.</dd>

<dt>POSIX2_PBS_CHECKPOINT</dt>

<dd>
The system supports the optional feature of checkpoint/restart within the Batch Environment Services and Utilities option.</dd>

<dt>POSIX2_PBS_LOCATE</dt>

<dd>
The system supports the optional feature of locating batch jobs within the Batch Environment Services and Utilities option.</dd>

<dt>POSIX2_PBS_MESSAGE</dt>

<dd>
The system supports the optional feature of sending messages to batch jobs within the Batch Environment Services and Utilities
option.</dd>

<dt>POSIX2_PBS_TRACK</dt>

<dd>
The system supports the optional feature of tracking batch jobs within the Batch Environment Services and Utilities option.</dd>

<dt>POSIX2_CHAR_TERM</dt>

<dd>
The system supports at least one terminal type capable of all operations described in IEEE&nbsp;Std&nbsp;1003.1-2001. 

<p>On systems with POSIX2_UPE, this option is almost always required. It was developed solely to allow certain specialized vendors
and user applications to bypass the requirement for general-purpose asynchronous terminal support. For example, an application and
system that was suitable for block-mode terminals, such as IBM 3270s, would not need this option.</p>

<p>XSI-conformant systems support this option.</p>
</dd>
</dl>

<h4><a name="tag_04_03_03"></a>Configurable Limits</h4>

<p>Very few of the limits need to be increased for profiles. No profile can cite lower values.</p>

<dl compact>
<dt>{POSIX2_BC_BASE_MAX}</dt>

<dt>{POSIX2_BC_DIM_MAX}</dt>

<dt>{POSIX2_BC_SCALE_MAX}</dt>

<dt>{POSIX2_BC_STRING_MAX}</dt>

<dd>
No increase is anticipated for any of these <a href="../utilities/bc.html"><i>bc</i></a> values, except for very specialized
applications involving huge numbers.</dd>

<dt>{POSIX2_COLL_WEIGHTS_MAX}</dt>

<dd>
Some natural languages with complex collation requirements require an increase from the default 2 to 4; no higher numbers are
anticipated.</dd>

<dt>{POSIX2_EXPR_NEST_MAX}</dt>

<dd>
No increase is anticipated.</dd>

<dt>{POSIX2_LINE_MAX}</dt>

<dd>
This number is much larger than most historical applications have been able to use. At some future time, applications may be
rewritten to take advantage of even larger values.</dd>

<dt>{POSIX2_RE_DUP_MAX}</dt>

<dd>
No increase is anticipated.</dd>

<dt>{POSIX2_VERSION}</dt>

<dd>
This is actually not a limit, but a standard version stamp. Generally, a profile should specify the Shell and Utilities volume of
IEEE&nbsp;Std&nbsp;1003.1-2001, <a href="../utilities/xcu_chap02.html">Chapter 2, Shell Command Language</a> by name in the
normative references section, not this value.</dd>
</dl>

<h4><a name="tag_04_03_04"></a>Configuration Options (System Interfaces)</h4>

<dl compact>
<dt>{NGROUPS_MAX}</dt>

<dd>
A non-zero value indicates that the implementation supports supplementary groups. 

<p>This option is needed where there is a large amount of shared use of files, but where a certain amount of protection is needed.
Many profiles<a href="#tag_foot_2"><sup><small>2</small></sup></a> are known to require this option; it should only be required if
needed, but it should never be prohibited.</p>
</dd>

<dt>_POSIX_ADVISORY_INFO</dt>

<dd>
The system provides advisory information for file management. 

<p>This option allows the application to specify advisory information that can be used to achieve better or even deterministic
response time in file manager or input and output operations.</p>
</dd>

<dt>_POSIX_ASYNCHRONOUS_IO</dt>

<dd>
The system provides concurrent process execution and input and output transfers. 

<p>This option was created to support historical systems that did not provide the feature. It should only be required if needed,
but it should never be prohibited.</p>
</dd>

<dt>_POSIX_BARRIERS</dt>

<dd>
The system supports barrier synchronization. 

<p>This option was created to allow efficient synchronization of multiple parallel threads in multi-processor systems in which the
operation is supported in part by the hardware architecture.</p>
</dd>

<dt>_POSIX_CHOWN_RESTRICTED</dt>

<dd>
The system restricts the right to &quot;give away&quot; files to other users. 

<p>This option should be carefully investigated before it is required. Some applications expect that they can change the ownership
of files in this way. It is provided where either security or system account requirements cause this ability to be a problem. It is
also known to be specified in many profiles.</p>
</dd>

<dt>_POSIX_CLOCK_SELECTION</dt>

<dd>
The system supports the Clock Selection option. 

<p>This option allows applications to request a high resolution sleep in order to suspend a thread during a relative time interval,
or until an absolute time value, using the desired clock. It also allows the application to select the clock used in a <a href=
"../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a> function call.</p>
</dd>

<dt>_POSIX_CPUTIME</dt>

<dd>
The system supports the Process CPU-Time Clocks option. 

<p>This option allows applications to use a new clock that measures the execution times of processes or threads, and the
possibility to create timers based upon these clocks, for runtime detection (and treatment) of execution time overruns.</p>
</dd>

<dt>_POSIX_FSYNC</dt>

<dd>
The system supports file synchronization requests. 

<p>This option was created to support historical systems that did not provide the feature. Applications that are expecting
guaranteed completion of their input and output operations should require the _POSIX_SYNC_IO option. This option should never be
prohibited.</p>

<p>XSI-conformant systems support this option.</p>
</dd>

<dt>_POSIX_IPV6</dt>

<dd>
The system supports facilities related to Internet Protocol Version 6 (IPv6). 

<p>This option was created to allow systems to transition to IPv6.</p>
</dd>

<dt>_POSIX_JOB_CONTROL</dt>

<dd>
Job control facilities are mandatory in IEEE&nbsp;Std&nbsp;1003.1-2001. 

<p>The option was created primarily to support historical systems that did not provide the feature. Many existing profiles now
require it; it should only be required if needed, but it should never be prohibited. Most applications that use it can run when it
is not present, although with a degraded level of user convenience.</p>
</dd>

<dt>_POSIX_MAPPED_FILES</dt>

<dd>
The system supports the mapping of regular files into the process address space. 

<p>XSI-conformant systems support this option.</p>

<p>Both this option and the Shared Memory Objects option provide shared access to memory objects in the process address space. The
functions defined under this option provide the functionality of existing practice for mapping regular files. This functionality
was deemed unnecessary, if not inappropriate, for embedded systems applications and, hence, is provided under this option. It
should only be required if needed, but it should never be prohibited.</p>
</dd>

<dt>_POSIX_MEMLOCK</dt>

<dd>
The system supports the locking of the address space. 

<p>This option was created to support historical systems that did not provide the feature. It should only be required if needed,
but it should never be prohibited.</p>
</dd>

<dt>_POSIX_MEMLOCK_RANGE</dt>

<dd>
The system supports the locking of specific ranges of the address space. 

<p>For applications that have well-defined sections that need to be locked and others that do not, IEEE&nbsp;Std&nbsp;1003.1-2001
supports an optional set of functions to lock or unlock a range of process addresses. The following are two reasons for having a
means to lock down a specific range:</p>

<ol>
<li>
<p>An asynchronous event handler function that must respond to external events in a deterministic manner such that page faults
cannot be tolerated</p>
</li>

<li>
<p>An input/output &quot;buffer&quot; area that is the target for direct-to-process I/O, and the overhead of implicit locking and unlocking
for each I/O call cannot be tolerated</p>
</li>
</ol>