Files
org-hyperion-cules/html/hercconf.html
2015-01-20 22:25:52 -08:00

4222 lines
180 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN" "html.dtd">
<html>
<head><title>
Hercules Version 4: Configuration File</title>
<link rel="Stylesheet" type="text/css" href="hercules.css"/>
</head>
<body bgcolor="#ffffcc" text="#000000" link="#0000A0"
vlink="#008040" alink="#000000">
<h1>Hercules Version 4: Configuration File</h1>
<p>
This page describes the configuration file for the Hercules S/370,
ESA/390, and z/Architecture emulator.
<p>
The configuration file <b><i>hercules.cnf</b></i> contains the
processor and device layout. It is roughly equivalent to the IOCDS on
a real System/390. The configuration file is an ASCII text file.
<h3>Example configuration file</h3>
<p>
Please note that the below example configuration file should not
be considered a good example of what an actual configuration file
looks like. It is only meant to illustrate what some
of the supported configuration file statements look like
and how they are used.
<p><br>
<center>
<table border=1><tr><td>
<pre><code>
####################################################################
# HERCULES EMULATOR CONTROL FILE #
# (Note: not all parameters are shown) #
####################################################################
#------------------------------------------------------------------
# <a href="#system_parameters">SYSTEM PARAMETERS</a>
#------------------------------------------------------------------
<a href="#ARCHLVL">##ARCHMODE</a> ESA/390 (deprecated)
<a href="#ASN_AND_LX_REUSE">##ASN_AND_LX_REUSE</a> disable (deprecated)
<a href="#ARCHLVL">ARCHLVL</a> ESA/390
<a href="#OSTAILOR">OSTAILOR</a> OS/390
<a href="#LOADPARM">LOADPARM</a> 0120....
<a href="#ARCHLVL_FACILITY">ARCHLVL</a> DISABLE ASN_LX_REUSE
<a href="#CPUSERIAL">CPUSERIAL</a> 000611
<a href="#CPUMODEL">CPUMODEL</a> 3090
<a href="#CPUVERID">CPUVERID</a> FD
<a href="#LPARNAME">LPARNAME</a> HERCULES
<a href="#LPARNUM">LPARNUM</a> 21
<a href="#MODEL">MODEL</a> EMULATOR
<a href="#PLANT">PLANT</a> ZZ
<a href="#MANUFACTURER">MANUFACTURER</a> HRC
<a href="#MAINSIZE">MAINSIZE</a> 64
<a href="#XPNDSIZE">XPNDSIZE</a> 0
<a href="#NUMCPU">NUMCPU</a> 1
<a href="#NUMVEC">NUMVEC</a> 1
<a href="#MAXCPU">MAXCPU</a> 8
<a href="#ENGINES">ENGINES</a> CP
<a href="#SYSEPOCH">SYSEPOCH</a> 1900
<a href="#YROFFSET">YROFFSET</a> -28
<a href="#TZOFFSET">TZOFFSET</a> -0500
<a href="#HTTPPORT">##HTTPPORT</a> 8081 NOAUTH (deprecated)
<a href="#HTTPROOT">##HTTPROOT</a> /usr/local/share/hercules/ (deprecated)
<a href="#HTTPPORT">HTTP</a> port 8081 NOAUTH
<a href="#HTTPROOT">HTTP</a> root /usr/local/share/hercules/
<a href="#HTTPSTRT">HTTP</a> start
<a href="#CCKD">CCKD</a> RA=2,RAQ=4,RAT=2,WR=2,GCINT=10,GCPARM=0,NOSTRESS=0,TRACE=0,FREEPEND=-1
<a href="#SHRDPORT">SHRDPORT</a> 3990
<a href="#SHOWDVOL1">SHOWDVOL1</a> NO
<a href="#PANTITLE">PANTITLE</a> "My own private MAINFRAME!"
<a href="#PANRATE">PANRATE</a> FAST
<a href="#LOGOPT">LOGOPT</a> TIMESTAMP
<a href="#CODEPAGE">CODEPAGE</a> default
<a href="#CNSLPORT">CNSLPORT</a> 3270
<a href="#CONKPALV">CONKPALV</a> (3,1,10)
<a href="#LEGACYSENSEID">LEGACYSENSEID</a> OFF
<a href="#HERCPRIO">HERCPRIO</a> 0
<a href="#TODPRIO">TODPRIO</a> -20
<a href="#DEVPRIO">DEVPRIO</a> 8
<a href="#CPUPRIO">CPUPRIO</a> 15
<a href="#SRVPRIO">SRVPRIO</a> 4
<a href="#TIMERINT">TIMERINT</a> DEFAULT
<a href="#TODDRAG">TODDRAG</a> 1.0
<a href="#DEVTMAX">DEVTMAX</a> 8
<a href="#DIAG8CMD">DIAG8CMD</a> disable
<a href="#SHCMDOPT">SHCMDOPT</a> disable
<a href="#DEFSYM">DEFSYM</a> TAPEDIR "<a href="#subs">$(HOME)</a>/tapes"
<a href="#AUTOMOUNT">AUTOMOUNT</a> $(TAPEDIR)
<a href="#AUTOMOUNT">AUTOMOUNT</a> +/tapes
<a href="#AUTOMOUNT">AUTOMOUNT</a> -/tapes/vault
<a href="#MODPATH">MODPATH</a> /usr/local/hercules
<a href="#LDMOD">LDMOD</a> dyncrypt
<a href="#PGMPRDOS">PGMPRDOS</a> restricted
<a href="#ECPSVM">ECPSVM</a> no
<a href="#SCSIMOUNT">SCSIMOUNT</a> no
<a href="#MOUNTED_TAPE_REINIT">MOUNTED_TAPE_REINIT</a> allow
<a href="#INCLUDE">INCLUDE</a> mydevs.cfg
<a href="#IGNORE">IGNORE</a> INCLUDE_ERRORS
<a href="#INCLUDE">INCLUDE</a> optdevs.cfg
#------------------------------------------------------------------
# <a href="#device_stmts">DEVICE STATEMENTS</a>
# (see supported <a href="#device_types_table">device types</a> table)
#------------------------------------------------------------------
0009 <a href="#consysc">3215-C</a> /
000A <a href="#1442">1442</a> adrdmprs.rdr
000C <a href="#3505">3505</a> jcl.txt ascii trunc
000D <a href="#3525">3525</a> pch00d.txt ascii
000E <a href="#1403">1403</a> prt00e.txt noclear
001E <a href="#1403">1403</a> 192.168.200.1:1403 sockdev
001F <a href="#3270">3270</a> * 192.168.0.1
0200.4 <a href="#3270">3270</a> * 192.168.0.0 255.255.255.0
0220.8 <a href="#3270">3270</a> GROUP1 192.168.100.0 255.255.255.0
0228.8 <a href="#3270">3270</a> GROUP2
0230.16 <a href="#3270">3270</a>
0000 <a href="#SYSG">SYSG</a> SYSGCONS
0120 <a href="#3380">3380</a> <a href="#ENHSYMINC">${DASD_PATH=dasd/}</a>mvsv5r.120
0121 <a href="#3380">3380</a> <a href="#ENHSYMINC">${DASD_PATH=dasd/}</a>mvsv5d.121
0122 <a href="#3380">3380</a> <a href="#ENHSYMINC">${DASD_PATH=dasd/}</a>mvswk1.122
0123 <a href="#3380">3380</a> 192.168.1.100
0140 <a href="#3370">3370</a> dosres.140
0141 <a href="#3370">3370</a> syswk1.141
0300 <a href="#3370">3370</a> sysres.300
0400 <a href="#CTCT">CTCT</a> 30880 192.168.100.2 30880 2048 &nbsp; &nbsp; &nbsp;
0401 <a href="#CTCT">CTCT</a> 30881 192.168.100.2 30881 2048
0420.2 <a href="#CTCI">CTCI</a> 192.168.200.1 192.168.200.2
0430.2 <a href="#CTCI">CTCI</a> tun0
0440.2 <a href="#LCS">LCS</a> -n /dev/net/tun 192.168.200.2
0460.2 <a href="#PTP">PTP</a> 192.168.200.1 192.168.200.2/24
0470.2 <a href="#PTP">PTP</a> tun0
0A00.3 <a href="#QETH">QETH</a> iface /dev/net/tun
0E40 <a href="#CTCE">CTCE</a> 31880 192.168.1.202 32880
0E41 <a href="#CTCE">CTCE</a> 31882 192.168.1.202 32882
0580 <a href="#3420">3420</a> /dev/nst0 # <a href="#SCSI">SCSI</a> (Linux or Windows)
0581 <a href="#3420">3420</a> \\.\Tape0 # <a href="#SCSI">SCSI</a> (Windows only)
0582 <a href="#3420">3420</a> ickdsf.aws <a href="#noautomount">noautomount</a>
0583 <a href="#3420">3420</a> /cdrom/tapes/uaa196.tdf
0584-0587 <a href="#3420">3420</a> <a href="#subs">$(TAPEDIR)</a>/volumes.<a href="#subs">$(CUU)</a> maxsizeM=170 eotmargin=131072
0590 <a href="#3420">3480</a> /dev/nst0 <a href="#Quantum">--no-erg</a> <a href="#Quantum">--blkid-32</a> # <a href="#Quantum">Quantum DLT SCSI</a>
0023 <a href="#comline">2703</a> lport=3780 rhost=localhost rport=3781 dial=no
00C3 <a href="#remtty">2703</a> lport=32003 dial=IN tty=1
</pre></code>
</td></tr></table>
</center>
<h3>Comment lines</h3>
<p>
Blank lines, and lines beginning with a &#035; sign
or an asterisk, are treated as comments.
<p>
<hr><!-- ---------------------------------------------------------------------------- -->
<a name="system_parameters"></a>
<h3>System parameters</h3>
<p>
Except for the ARCHLVL statements, system parameter statements may appear
in any order but must precede any device statements. Each system parameter
must be on a separate line. The following system parameters may be specified:
<dl>
<a name="ARCHLVL"></a>
<dt><code>ARCHLVL &nbsp; S/370 &#124; ESA/390 &#124; ESAME &#124; <u>z/Arch</u></code>
<dd><p>
specifies the initial architecture mode:<p>
<ul compact>
<li>use <code>S/370</code> for OS/360, VM/370, and MVS 3.8.
<li>use <code>ESA/390</code> for MVS/XA, MVS/ESA, OS/390, VM/ESA, VSE/ESA,
Linux/390, and ZZSA.
<li>use <code>z/Arch</code> or <code>ESAME</code> for z/OS and zLinux. This is the default.
</ul>
<p><code>ESAME</code> is similar to <code>z/Arch</code>.
When <code>z/Arch</code> or <code>ESAME</code> is specified,
the machine will always IPL in ESA/390 mode,
but is capable of being switched into z/Architecture mode after IPL.
This is handled automatically by all z/Architecture operating systems.
<p>
The <code>ESAME</code> mode is equivalent to z/Architecture mode at Architecture Level 2.
The <code>z/Arch</code> mode is equivalent to z/Architecture mode at Architecture Level 3.
The synonyms ALS0, ALS1, ALS2 and ALS3 may be used to specify S/370, ESA/390, ESAME or Z/Arch respectively.
<p>
Note: This statement used to be called <code>ARCHMODE</code> in previous versions of Hercules
but the use of <code>ARCHMODE</code> has been deprecated in favor of the new <code>ARCHLVL</code>
statement. Existing <code>ARCHMODE</code> statements should be changed to <code>ARCHLVL</code>
instead.
<p>
For the time being however, <code>ARCHMODE</code> is still accepted and is treated as
simply a synonym for the <code>ARCHLVL</code> statement.
<p>
<a name="ARCHLVL_FACILITY"></a>
<dt><code>ARCHLVL &nbsp; ENABLE &#124; DISABLE &#124; QUERY &nbsp;<em>facility</em> &nbsp;<em>[archmode]</em></code>
<dd><p>
specifies a particular STFLE facility to be enabled or disabled, or a query of the current settings.
Use <code>QUERY ALL</code> to obtain a list of valid <code><em>facility</em></code> &nbsp;names
that may be used for the given archmode.
<p>
Alternatively, you can also specify the actual STFLE bit number to be turned off or on
(disabled or enabled) using the format <code><em>BITnn</em></code> &nbsp;where 'nn'
corresponds to the exact STFLE facility bit you wish to be forced on or off. A popular
one among the VM crowd is <code>ENABLE BIT44</code> to force the PFPO Facility bit on.
<p>
The optional <code><em>archmode</em></code> &nbsp;argument limits the enable,
disable or query function to a specific <a href="#ARCHLVL">architecture</a>.
It should be noted that attempts to enable or disable a facility that a given
architecture does not support are ignored without error. The default value is
whatever architecture mode was previously established by a preceding
<a href="#ARCHLVL">ARCHLVL</a> statement or the default mode if there was no
preceding ARCHLVL statement.
<p>
<a name="ASN_AND_LX_REUSE"></a>
<dt><code>ASN_AND_LX_REUSE &nbsp; <u>DISABLE</u> &#124; ENABLE</code> &nbsp; &nbsp; &nbsp; <i>(deprecated)</i>
<dd><p>
specifies that the ASN-and-LX-Reuse Facility (ALRF) is to be disabled
or enabled. The default is disabled. This is a z/Architecture-only
feature (it is always disabled for S/390 or ESA/390). Set this
to <code>ENABLE</code> &nbsp;if the operating system supports
this z/Architecture feature and the use of this feature is desired.
Set it to <code>DISABLE</code> &nbsp;or do not specify anything
if the operating system doesn't support this feature, and it
inadvertently sets CR0 bit 44 to 1, usually leading to unexpected
program interrupt when instructions such as LASP are issued.
<p>
<code>ASN_AND_LX_REUSE</code> may be abbreviated as <code>ALRF</code>.
<p>
<b>Note:</b> The <code>ASN_AND_LX_REUSE</code> statement has been superseded
by "<code>ARCHLVL ENABLE/DISABLE ASN_LX_REUSE</code>" and is thus deprecated.
Existing <code>ALRF</code> or <code>ASN_AND_LX_REUSE</code> statements
should be changed to use the new <a href="#ARCHLVL_FACILITY">ARCHLVL
facility</a> statement format instead.
<p>
<a name="AUTOMOUNT"></a>
<dt><code>AUTOMOUNT &nbsp; <em>[&plusmn;]directory</em></code>
<dd><p>
specifies the host system directory where the guest is allowed
or not allowed to automatically load virtual tape volumes from.
Prefix allowable directories with a '+' plus sign and unallowable
directories with a '-' minus sign. The default prefix if neither is
specified is the '+' plus sign (i.e. an allowable directory).
<p>
<i><b>Caution:</b> &nbsp;Enabling this feature may have security
consequences depending on which allowable host system directories you
specify as well as how your guest operating system enforces
authorized use of the Set Diagnose (X'4B') channel command code.
</i>
<p>
All host system virtual tape volumes to be "automounted" by the guest
must reside within one of the specified allowable host system directories
or any of its subdirectories while not also being within any of the
specified unallowable directories or any of their subdirectories,
in order for the guest-invoked automount to be accepted.
<p>
Note: specifying a disallowed automount directory does not preclude the
Hercules operator from manually mounting any desired file via the
<code>devinit</code> panel command -- even one in a currently defined
"disallowed" automount directory. The AUTOMOUNT statement only controls
guest-invoked automatic tape mounts and not manual tape mounts performed
by the Hercules operator.
<p>
All directories must be specified on separate statements, but as many
statements as needed may be specified in order to describe the desired
allowable/unallowable directories layout. For convenience, an
<code>automount</code> panel command is also provided to dynamically
add/remove new/existing allowable/unallowable automount
directories at any time.
<p>
The automount feature is activated whenever you specify at least
one allowable or unallowable directory. If only
unallowable directories are specified, then the current directory
becomes the only defined allowable automount directory by default.
<p>
All specified directories are always resolved to fully-qualified
absolute directory paths before being saved.
<p>
Refer to the description of the virtual tape device
'<a href="#noautomount">noautomount</a>' option for more information.
<p>
<a name="CCKD"></a>
<dt><code>CCKD &nbsp; <em>cckd-parameters</em></code>
<dd><p>
The CCKD command and initialization statement can be used to affect
cckd processing. The CCKD initialization statement is specified as
a Hercules configuration file statement and supports the same options
as the cckd panel command. Refer to the
<a href="cckddasd.html#cckdcommand">Compressed Dasd Emulation</a>
web page for more information.
<p>
<a name="CMPSCPAD"></a>
<dt><code>CMPSCPAD &nbsp; <em>alignment</em></code>
<dd><p>
The CMPSCPAD command and initialization statement is used to define
the zero padding storage alignment boundary for the CMPSC-Enhancement
Facility. It must be a power of 2 value ranging anywhere from 1 to 12.
<p>
<a name="CODEPAGE"></a>
<dt><code>CODEPAGE &nbsp; <em>mapping</em></code>
<dd><p>
specifies the codepage conversion mapping table used for ASCII/EBCDIC translation.
<p>
<code>default</code> specifies traditional Hercules codepage mapping.
<p>
Other supported codepage mappings are:
<p>
<blockquote>
<table border=1 cellpadding=3>
<tr>
<th rowspan=2>Mapping</th>
<th colspan=2>Description</th>
</tr>
<tr>
<th>ASCII</th>
<th>EBCDIC</th>
</tr>
<tr><td align="center"><code>437/037</code></td>
<td>437 PC United States</td>
<td>037 United States/Canada</td>
<tr><td align="center"><code>437/500</code></td>
<td>437 PC United States</td>
<td>500 International</td>
</tr>
<tr><td align="center"><code>437/1047</code></td>
<td>437 PC United States</td>
<td>1047 Open Systems Latin 1</td>
</tr>
<tr><td align="center"><code>819/037</code></td>
<td>819 ISO-8859-1</td>
<td>037 United States/Canada</td>
</tr>
<tr><td align="center"><code>819/037v2</code></td>
<td>819 ISO-8859-1</td>
<td>037 United States/Canada version 2</td>
</tr>
<tr><td align="center"><code>819/273</code></td>
<td>819 ISO-8859-1</td>
<td>273 Austria/Germany</td>
</tr>
<tr><td align="center"><code>819/277</code></td>
<td>819 ISO-8859-1</td>
<td>277 Denmark/Norway</td>
</tr>
<tr><td align="center"><code>819/278</code></td>
<td>819 ISO-8859-1</td>
<td>278 Finland/Sweden</td>
</tr>
<tr><td align="center"><code>819/280</code></td>
<td>819 ISO-8859-1</td>
<td>280 Italy</td>
</tr>
<tr><td align="center"><code>819/284</code></td>
<td>819 ISO-8859-1</td>
<td>284 Spain</td>
</tr>
<tr><td align="center"><code>819/285</code></td>
<td>819 ISO-8859-1</td>
<td>285 United Kingdom</td>
</tr>
<tr><td align="center"><code>819/297</code></td>
<td>819 ISO-8859-1</td>
<td>297 France</td>
</tr>
<tr><td align="center"><code>819/500</code></td>
<td>819 ISO-8859-1</td>
<td>500 International</td>
</tr>
<tr><td align="center"><code>819/1047</code></td>
<td>819 ISO-8859-1</td>
<td>1047 Open Systems Latin 1</td>
</tr>
<tr><td align="center"><code>850/273</code></td>
<td>850 PC Latin 1</td>
<td>273 Austria/Germany</td>
</tr>
<tr><td align="center"><code>850/1047</code></td>
<td>850 PC Latin 1</td>
<td>1047 Open Systems Latin 1</td>
</tr>
<tr><td align="center"><code>1252/037</code></td>
<td>1252 Windows Latin 1</td>
<td>037 United States/Canada</td>
</tr>
<tr><td align="center"><code>1252/037v2</code></td>
<td>1252 Windows Latin 1</td>
<td>037 United States/Canada version 2</td>
</tr>
<tr><td align="center"><code>1252/1047</code></td>
<td>1252 Windows Latin 1</td>
<td>1047 Open Systems Latin 1</td>
</tr>
<tr><td align="center"><code>1252/1140</code></td>
<td>1252 Windows Latin 1</td>
<td>1140 United States/Canada with Euro</td>
</tr>
</table>
</blockquote>
<p>
If no codepage is specified then the environment variable HERCULES_CP
will be inspected. The default codepage mapping is <code>default</code>.
<p>
<a name="CNSLPORT"></a>
<dt><code>CNSLPORT &nbsp; <i>nnnn</i></code>
<dd><p>
specifies the port number (in decimal) to which tn3270 and
telnet clients will connect.
<p>
The CNSLPORT statement may also have the form of host:port, where
the telnet console server will bind to the specified address.
<p>
<a name="CONKPALV"></a>
<dt><code>CONKPALV &nbsp; <i>(idle,intv,count)</i></code>
<dd><p>
specifies the tn3270 console and telnet clients keepalive option
values that control automatic detection of disconnected tn3270/telnet
client sessions.
<p>
<code><i>idle</i></code> &nbsp;specifies the number of seconds
of inactivity until the first keepalive probe is
sent (idle time until first probe, or probe frequency).
<br><code><i>intv</i></code> &nbsp;
specifies the interval in seconds between when successive
keepalive packets are sent if no acknowledgement is received from
the previous one (i.e. the timeout value of the probes themselves).
<br><code><i>count</i></code> &nbsp;specifies the number of unacknowledged
keepalive packets sent before the connection is considered to have
failed.
<p>
The default values for Windows are 3, 1, and 10. For non-Windows systems
it is 3, 1, and 9. That is, send the initial probe 3 seconds after the
connection goes idle and then wait no more than one second for it to be
responded to. If it is not responded to within one second, then send up
to 9 more probes (for a total of 10), each of which must also timeout
without being responded to before the client is considered as having
died and the connection thus automatically closed.
<p>
<i><b>Note:</b></i>
This is a built-in feature of TCP/IP and allows detection of
unresponsive TCP/IP <i>connections</i> and not idle clients.
That is to say, your connection will <i>not</i> be terminated
after 3 seconds of idle time. Your 3270 session can remain idle for
many minutes or hours or days without any data being transmitted.
If the TCP/IP <i>stack</i> at the other end of the connection --
not your 3270 client itself -- fails to respond to the
internal keepalive probe packets however, then it means that the
TCP/IP stack itself is down or there has been a physical break
in the connection.
<p>
Thus, even if your 3270 client is completely idle, your system's TCP/IP stack
itself should still respond to the keepalive probes sent by the TCP/IP stack
at the Hercules end of the link. If it doesn't, then TCP/IP will terminate
the tn3270/telnet session which will cause Hercules to disconnect the terminal.
<p>
The three values can also be modified on-demand via the <code>conkpalv</code>
panel command, which has the exact same syntax. Note that the syntax is
very unforgiving: no spaces are allowed anywhere within the parentheses
and each value must be separated from the other with a single comma.
<p>
<b>Please also note</b> that not all systems support being able to modify
all three values. That is, not all values may be able to be changed, and it
is system dependent which values you can change and which values you cannot.
On Windows for example, the <code><i>count</i></code> value is ignored
and cannot be changed from its default value of 10. Other systems may
ignore one or more or all three values and use platform defaults instead.
This is entirely system dependent. Check you system's documentation for details
regarding which values can be changed and which cannot as well as how to
adjust your system's default values.
<p>
<a name="CPUMODEL"></a>
<dt><code>CPUMODEL &nbsp; <em>xxxx</em></code>
<dd><p>
specifies the 4 hexadecimal digit CPU machine type number
stored by the STIDP instruction
<i>Note: Prior to ESA/390 this was known as the CPU model number</i>
<p>
<a name="CPUPRIO"></a>
<dt><code>CPUPRIO &nbsp; <em>nn</em></code>
<dd><p>
specifies the priority of the CPU thread. Default is a nice value
of 15, which means a low priority such that I/O can be scheduled and
completed in favour of CPU cycles being burned. On Multi-CPU
systems, a real CPU can be "dedicated" to Hercules, by giving the
CPU thread a very high dispatching priority (-20).
See <a href="#thread_priorities">"Thread Priorities"</a>
below for more information.
<p>
<i><b>Caution:</b> &nbsp;CPUPRIO should not have a higher dispatching
priority than the TOD Clock and timer thread.</i>
</ol>
<p>
<a name="CPUSERIAL"></a>
<dt><code>CPUSERIAL &nbsp; <em>xxxxxx</em></code>
<dd><p>
specifies the 6 hexadecimal digit CPU serial number stored by the
STIDP instruction. In BASIC mode, the high-order digit may be
replaced with the processor number when MAXCPU > 1; in LPAR mode,
the two high-order digits are replaced with either the LPAR number
or the CPU number and LPAR number with the full serial number
available via the STSI instruction.
The default serial number is 000001.
<p>
<a name="CPUVERID"></a>
<dt><code>CPUVERID &nbsp; <em>xx</em></code>
<dd><p>
specifies the 2 hexadecimal digit CPU version code
stored by the STIDP instruction.
The default version code is FD when ARCHLVL S/370 or ARCHLVL ESA/390
is specified. For the z/Architecture mode, the version code is always
stored as 00 and the value specified here is ignored.
<p>
<a name="DEFSYM"></a>
<dt><code>DEFSYM &nbsp; <em>symbol</em> <em>value</em></code>
<dd><p>
Defines symbol <em>symbol</em> as to contain value <em>value</em>. The
symbol can then be the object of a substitution later in the configuration
file or for panel commands. If <em>value</em> contains blanks or spaces, then
it should be enclosed in double quotation marks (&quot;). See
<a href="#subs">substitutions</a> for a more in-depth discussion
on this feature.
<p>
Substitution is available even in configuration statements,
meaning it is possible to perform substitution in the <em>DEFSYM</em> statement itself.
However, symbols are always defined as the last step in the process, so attempting
to self define a symbol will result in an empty string:
<code><pre>
DEFSYM FOO $(FOO)</pre></code>
Will set symbol FOO to &quot;&quot;
<p>
<a name="DEVPRIO"></a>
<dt><code>DEVPRIO &nbsp; <em>nn</em></code>
<dd><p>
specifies the priority of the device threads. The default value is 8.
See <a href="#thread_priorities">"Thread Priorities"</a>
below for more information.
<p>
<i><b>Caution:</b> &nbsp;DEVPRIO should not have a higher dispatching
priority than the TOD Clock and timer thread.</i>
<p>
<a name="DEVTMAX"></a>
<dt><code>DEVTMAX &nbsp; -1 &#124; 0 &#124; <em>nnn</em></code>
<dd><p>
specifies the maximum number of device threads allowed.
<p>Specify <code>-1</code> to cause 'one time only' temporary threads to be
created to service each I/O request to a device. Once the I/O request is
complete, the thread exits. Subsequent I/O to the same device will cause
another worker thread to be created again.
<p>Specify <code>0</code> to cause an unlimited number of 'semi-permanent'
threads to be created on an 'as-needed' basis. With this option, a thread
is created to service an I/O request for a device if one doesn't already
exist, but once the I/O is complete, the thread enters an idle state waiting
for new work. If a new I/O request for the device arrives before the timeout
period expires, the existing thread will be reused. The timeout value is
currently hard coded at 5 minutes. Note that this option can cause one thread
(or possibly more) to be created for each device defined in your
configuration. Specifying <code>0</code> means there is no limit to the
number of threads that can be created.
<p>Specify a value from <code>1</code> to <code><em>nnn</em></code> &nbsp;to set an upper limit
to the number of threads that can be created to service any I/O request to
any device. Like the <code>0</code> option, each thread, once done servicing
an I/O request, enters an idle state. If a new request arrives before the
timeout period expires, the thread is reused. If all threads are busy when
a new I/O request arrives however, a new thread is created <i>only</i> if the
specified maximum has not yet been reached. If the specified maximum number
of threads has already been reached, then the I/O request is placed in a queue
and will be serviced by the first available thread (i.e. by whichever thread
becomes idle first). This option was created to address a threading issue
(possibly related to the cygwin Pthreads implementation) on Windows systems.
<p>The default for Windows is <code>8</code>. The default for all other systems
is <code>0</code>.
<p>
<a name="DIAG8CMD"></a>
<dt><code>DIAG8CMD &nbsp; <u>DISABLE</u> &#124; ENABLE [ECHO &#124; <u>NOECHO</u>]</code>
<dd><p>
When <code>ENABLE</code> is specified, commands issued through the Diagnose 8 interface
will be executed by Hercules as Hercules commands. When set to <code>DISABLE</code>,
commands issued through the Diagnose 8 interface will generate a Specification
Exception program interrupt on the issuing CPU.
<p>An optional second argument can be given to request whether the commands
issued using the Diagnose 8 interface will be traced at the console. This may be
useful for programs that routinely issue panel commands using the Diagnose 8 interface.
When <code>ECHO</code> is specified, a message is issued as the panel is about to issue
the command, the command is redisplayed as if it was entered through the panel input
line, and a final message is issued to indicate the command completed. When <code>NOECHO</code>
is specified, no such messages are displayed and the command completes silently.
<p>The value of <code>ECHO</code> or <code>NOECHO</code> has no effect on
command output being placed into a response buffer if the Diagnose 8 interface
requested one.
<p>The default is <code>DISABLE NOECHO</code>
<p>
<i><b>Caution:</b> &nbsp;Enabling this feature may have security consequences.</i>
<p>
When this feature is enabled it is possible for guest operating systems
running under Hercules to issue commands directly to the host operating system
by means of the Hercules <code>sh</code> (shell) command. This ability may be
disabled via the <a href="#SHCMDOPT">SHCMDOPT</a> statement.
<p>
<a name="ECPSVM"></a>
<dt><code>ECPSVM &nbsp; YES &#124; NO &#124; LEVEL <em>nn</em></code>
<dd><p>
specifies whether ECPS:VM (Extended Control Program Support : Virtual Machine)
support is to be enabled. If <code>YES</code> is specified, then the support
level reported to the operating system is <code>20</code>. The purpose of
ECPS:VM is to provide to the VM/370 Operating system a set of shortcut
facilities to perform hypervisor functions (CP Assists) and virtual
machine simulation (VM Assists). Although this feature does not affect
VM Operating system products operating in XA, ESA or z/Architecture mode,
it will affect VM/370 and VM/SP products running under VM/XA, VM/ESA or z/VM.
Running VM/370 and VM/SP products under VM/XA, VM/ESA or z/VM should be
done with ECPS:VM disabled. ECPS:VM should not be enabled in an AP or MP
environment. ECPS:VM has no effect on non-VM operating systems. It is
however recommended to disable ECPS:VM when running native non-VM operating
systems. If a specific LEVEL is specified, this value will be reported
to the operating system when it issues a Store ECPS:VM level, but it
doesn't otherwise alter the ECPS:VM facility operations. This is a partial
implementation.
<p>
<a name="ENGINES"></a>
<dt><code>ENGINES &nbsp; [<em>nn</em>*]<u>CP</u>&#124;IL&#124;AP&#124;IP[,...]</code>
<dd><p>
specifies the type of engine for each installed processor.
The default engine type is CP.
<p>
<em>nn</em>* is an optional repeat count.
Spaces are not permitted.
<p>
Examples:
<p>
<code>ENGINES CP,CP,AP,IP</code>
<br>specifies that processor engines 0 and 1 are of type CP, engine 2 is
type AP, and engine 3 is type IP.
<p>
<code>ENGINES 4*CP,2*AP,2*IP</code>
<br>specifies that the first four processor engines (engines 0-3) are of
type CP, the next two (engines 4-5) are of type AP, and the next two
(engines 6-7) are of type IP.
<p>
The number of installed processor engines is determined by the
<a href="#MAXCPU">MAXCPU</a> statement.
If the ENGINES statement specifies more than MAXCPU engines, the excess
engines are ignored. If fewer than MAXCPU engines are specified, the
remaining engines are set to type CP.
<p>
<a name="HERCPRIO"></a>
<dt><code>HERCPRIO &nbsp; <em>nn</em></code>
<dd><p>
specifies the process priority for Hercules. The default is 0.
See <a href="#process_priorities">"Process Priorities"</a>
below for more information.
<p>
<a name="HTTPPORT"></a>
<dt><code>HTTP PORT &nbsp; <em>nnnn</em> [[NOAUTH] &#124; [AUTH <em>userid password</em>]]</code>
<dd><p>
specifies the port number (in decimal) on which the HTTP server
will listen. The port number must either be 80
or within the range 1024 - 65535 inclusive. The server is not start until a subsequent
<code><a href="#HTTPSTRT">HTTP START</a></code> statement is found.
<p>
<tt>AUTH</tt> indictates that a userid and password are required to access
the HTTP server, whereas <tt>NOAUTH</tt> indicates that a userid and password
are not required. The userid and password may be any valid string.
<p>
Note: <code>HTTPPORT nnnn [[NOAUTH] &#124; [AUTH <em>userid password</em>]]</code> is still supported,
however, it has been deprecated.
<p>
<a name="HTTPROOT"></a>
<dt><code>HTTP ROOT &nbsp; <em>directory</em></code>
<dd><p>
specifies the root directory where the HTTP server's files reside.
If not specified, the default value for Win32 builds of Hercules is the
directory where the Hercules executable itself is executing out of, and for
non-Win32 builds it is the directory specified as the default package
installation directory when the Hercules executable was built (which can
vary depending on how the Hercules package was built, but is usually
<tt>/usr/local/share/hercules/</tt>).
<p>
Note: <code>HTTPROOT <em>directory </em></code> &nbsp;is still supported, however, it has been deprecated.
<p>
<a name="HTTPSTRT"></a>
<dt><code>HTTP START</code>
<dd><p>
starts the HTTP server. (Note: The server is no longer started by default.)
<p>
<a name="IGNORE"></a>
<dt><code>IGNORE &nbsp; INCLUDE_ERRORS</code>
<dd><p>
Indicates that errors caused by subsequent
<code><a href="#INCLUDE">INCLUDE</a></code> statements
for files which do not exist should instead be ignored rather
than causing startup to be aborted (as would otherwise normally
occur).
<p>
<a name="INCLUDE"></a>
<dt><code>INCLUDE &nbsp; <em>filepath</em></code>
<dd><p>
An <code>INCLUDE</code> statement tells Hercules configuration file
processing to treat the contents of the file specified by <em>filepath</em>
as if its contents had appeared in the configuration file at the point
where the <code>INCLUDE</code> statement appears.
<p>
Note that the included file may itself contain yet another
<code>INCLUDE</code> statement as long as the maximum nesting depth
(current 8) is not exceeded.
<p>
<a name="IODELAY"></a>
<dt><code>IODELAY &nbsp; <em>usec</em></code>
<dd><p>
specifies the amount of time (in microseconds) to wait after
an I/O interrupt is ready to be set pending. This value can also be
set using the Hercules console. The purpose of this parameter is to
bypass a bug in the <b>Linux/390</b> and <b>zLinux</b> <code>dasd.c</code>
device driver. The problem is more apt to happen under Hercules than
on a real machine because we may present an I/O interrupt sooner than a
real machine.
<p>
NOTE : <a href="#OSTAILOR"><code>OSTAILOR LINUX</code></a> no longer sets
IODELAY to 800 since the problem described above is no longer present in
recent versions of the Linux kernel.
<p>
<a name="LDMOD"></a>
<dt><code>LDMOD &nbsp; <em>module list</em></code>
<dd><p>
specifies additional modules that are to be loaded by the Hercules dynamic loader.
The default search order is with the hercules directory in the default DLL search
path. Most systems also support absolute filenames (ie names starting with '/'
or '.') in which case the default search path is not taken.
<p>
Multiple LDMOD statements may be used.
<p>
<a name="LEGACYSENSEID"></a>
<dt><code>LEGACYSENSEID &nbsp; <u>OFF</u> &#124; <u>DISABLE</u> &#124; ON &#124; ENABLE</code>
<dd><p>
specifies whether the SENSE ID CCW (X'E4') will be honored for
the devices that originally didn't support that feature. This
includes (but may not be limited to) 3410 and 3420 tape drives,
2311 and 2314 direct access storage devices,
and 2703 communication controllers.
<p>
Specify <code>ON</code> or <code>ENABLE</code> if your guest
operating system needs the Sense ID support to dynamically
detect those devices. Note that most current operating systems
will not detect those devices even though Sense ID is enabled
because those devices never supported the Sense ID in the first
place. So this mainly applies to custom built or modified versions
of guest operating systems that are aware of this specific Hercules
capability.
<p>
Because those legacy devices didn't originally support this command,
and for compatibility reasons, the default is <code>OFF</code>
or <code>DISABLE</code>.
<p>
<a name="LOADPARM"></a>
<dt><code>LOADPARM &nbsp; <em>xxxxxxxx</em></code>
<dd><p>
specifies the eight-character IPL parameter which is used
by some operating systems to select system parameters.
<p>
<a name="LOGOPT"></a>
<dt><code>LOGOPT &nbsp; <u>TIMESTAMP</u> &#124; NOTIMESTAMP</code>
<dd><p>
sets Hercules log options. TIMESTAMP causes messages to the log
to be time stamped. NOTIMESTAMP prevents time stamping of log
messages. TIMESTAMP and NOTIMESTAMP may be abbreviated as
TIME and NOTIME respectively. The current resolution of the
stamp is one second.
<p>
The default is TIMESTAMP.
<p>
<a name="LPARNAME"></a>
<dt><code>LPARNAME &nbsp; <em>name</em></code>
<dd><p>
specifies the LPAR name returned by DIAG X'204'. The default is
<code>HERCULES</code>.
<p>
<a name="LPARNUM"></a>
<dt><code>LPARNUM &nbsp; <em>xx</em> &#124; BASIC</code>
<dd><p>
specifies the one- or two-digit hexadecimal LPAR identification
number stored by the STIDP instruction, or BASIC. If a one-digit
number from 1 to F (hexadecimal) is specified, then STIDP stores a
format-0 CPU ID unless a subsequent CPUIDFMT 1 statement is
specified. If zero or a a two-digit hexadecimal number, except 10
(hexadecimal), is specified, then STIDP stores a format-1 CPU ID.
For LPARNUM 10, the current CPUIDFMT is not changed. If LPARNUM is
BASIC, then STIDP stores a basic-mode CPU ID.
The default is LPARNUM 1 with a format-0 CPU ID.
<p>
<a name="MAINSIZE"></a>
<dt><code>MAINSIZE &nbsp; <em>nnnn</em> &#124;
<em>nnn</em>K &#124;
<em>nnn</em>M &#124;
<em>nnn</em>G &#124;
<em>nnn</em>T &#124;
<em>nnn</em>P &#124;
<em>nnn</em>E</code>
<dd><p>
specifies the main storage size in megabytes, where
<code><em>nnnn</em></code> &nbsp;is a decimal number. Or,
<code><em>nnnM</em></code> &nbsp;where <code><em>M</em></code>&nbsp;
is K - Kilobytes, M - Megabytes, G - Gigabytes, T - Terabytes,
P - Petabytes, E - Exabytes. The default on startup is 2M.
<p>
For storage sizes less than 16M, sizes not on a 4K boundary are
rounded up to the next 4K boundary. Otherwise, storage sizes not on
a 1M boundary are rounded up to the next 1M boundary.
<p>
The minimum size is 4K for archlvl als0 and als1 (S/370 and
ESA/390), and 8K for archlvl als2 (ESAME) and higher. A maximum of
64M may be specified for archlvl als0 (S/370), 2048M (2G) for
archlvl als1 (ESA/390), and 16E for archlvl als2 (ESAME) and higher.
<p>
<b>Notes:</b>
<ol><p><li>
The actual upper limit is determined by your host system's
architecture and operating system, the guest operating system, and
the amount of physical memory and available paging space. The total
of mainsize and xpndsize on host systems with a 32-bit architecture
will be limited to less than 4G; host systems with a 64-bit
architecture will be limited to less than 16E.
</li><p><li>
Using minimum storage sizes, storage sizes less than or not on a 64K
boundary for archlvl als1 (S/370), or on a 1M boundary for archlvl
als2 (ESA/390) and higher, it may be possible to generate error
conditions not covered by the Principles of Operations.
</li><p><li>
Use of storage sizes greater than supported by the guest operating
system may generate incorrect results or error conditions within the
guest operating system.
</li></ol>
<p>
<a name="MANUFACTURER"></a>
<dt><code>MANUFACTURER &nbsp; <em>name</em></code>
<dd><p>
specifies the MANUFACTURER name returned the STSI instruction. The default is
<code>HRC</code>.
<p>
<a name="MAXCPU"></a>
<dt><code>MAXCPU &nbsp; <em>nn</em></code>
<dd><p>
specifies the number of installed processor engines.
The <a href="#NUMCPU">NUMCPU</a> statement specifies the number of
engines which will be configured online at startup time.
All processors are CP engines unless otherwise specified by the
<a href="#ENGINES">ENGINES</a> statement.
<p>
The value of MAXCPU cannot exceed the value of <code>MAX_CPU_ENGINES</code>.
If MAXCPU is not specified in the Hercules configuration file,
then its initial value is equal to NUMCPU.
If MAXCPU and NUMCPU are both omitted, MAXCPU is set to 1.
<p>
<code>MAX_CPU_ENGINES</code> is a compile-time variable which sets
an upper limit on the value of MAXCPU.
The value of <code>MAX_CPU_ENGINES</code> is displayed in the
Build information message on the Hercules control panel at startup time.
To change the value of <code>MAX_CPU_ENGINES</code> you must rebuild
Hercules.
For Unix builds, specify
<tt>./configure --enable-multi-cpu=<em>nn</em></tt>
before performing make.
For Windows builds, specify
<tt>SET MAX_CPU_ENGINES=<em>nn</em></tt>
before performing nmake.
<p>
<code>MAX_CPU_ENGINES</code> cannot exceed 64. For performance reasons,
values above 32 are not recommended for 32-bit platforms.
If <code>MAX_CPU_ENGINES</code> is set to 1 then multiprocessing is disabled.
See also <a href="#NUMCPU">NUMCPU</a> for a discussion of the performance
implications of <code>MAX_CPU_ENGINES</code>.
<p>
<a name="MODEL"></a>
<dt><code>MODEL &nbsp; <em>hardware_model</em>
[ <em>capacity_model</em> ]
[ <em>perm_capacity_model</em> ]
[ <em>temp_capacity_model</em> ]
</code>
<dd><p>
specifies the MODEL names returned by the STSI instruction.
<p>
If two operands are supplied, the first is the hardware model name (CPC
ND model) and the second is the capacity model name (CPC SI model).
If only one operand is supplied, it is used as both the hardware model
name and the capacity model name.
The optional third and fourth operands specify the permanent capacity
model name and the temporary capacity model name respectively.
<p>
The default is <code>EMULATOR</code>.
<p>
<a name="MODPATH"></a>
<dt><code>MODPATH &nbsp; <em>path</em></code>
<dd><p>
specifies the path where dynamic modules are loaded from. When a modpath
statement is specified, the path on the modpath statement is searched before
the default path is searched. When a relative path is specified is interpreted
as a relative path within the default search path, if an absolute path is
specified is interpreted as such.
<p>
The default MODPATH is hercules, which means modules are loaded from the
directory hercules within the default LD_LIBRARY_PATH.
<p>
<a name="MOUNTED_TAPE_REINIT"></a>
<dt><code>MOUNTED_TAPE_REINIT &nbsp; DISALLOW &#124; DISABLE &#124; <u>ALLOW</u> &#124; <u>ENABLE</u> </code>
<dd><p>
specifies whether reinitialization of tape drive devices (via the
<code>devinit</code> command, in order to mount a new tape) should
be allowed if there is already a tape mounted on the drive.
<p>
Specifying <code>ALLOW</code>&#124;<code>ENABLE</code> (default) indicates new tapes may
be mounted (via <code>'devinit <i>nnnn</i> <i>new-tape-filename</i>'</code>)
irrespective of whether or not there is already a tape mounted on the drive.
<p>
Specifying <code>DISALLOW</code>&#124;<code>DISABLE</code> prevents new tapes from being mounted
if one is already mounted. When <code>DISALLOW</code> is specified
and a tape is already mounted on the drive, it must first be unmounted
(via the command <code>'devinit <i>nnnn</i> *'</code>) before
the new tape can be mounted. Otherwise the devinit attempt to mount
the new tape is rejected.
<p>
This option is meant as a safety mechanism to protect against
accidentally dismounting a tape from the wrong drive as a result of
a simple typo (thereby cancelling a potentially important tape job)
and was added by user request.
<p>
Also note that for SCSI tape drives the <code>'devinit <i>nnnn</i> *'</code>
command has no effect as the tape must be unmounted manually (since it is
a real physical device and not one emulated via a disk file like .AWS tapes).
<p>
<a name="NUMCPU"></a>
<dt><code>NUMCPU &nbsp; <em>nn</em></code>
<dd><p>
specifies the number of emulated processor engines
which will be configured online at startup time.
NUMCPU cannot exceed the value of <a href="#MAXCPU">MAXCPU</a>.
If NUMCPU is less than <a href="#MAXCPU">MAXCPU</a>
then the remaining engines can be configured online later.
The default NUMCPU value is 1. The minimum value is 0.
<p>
Multiprocessor emulation works best
if your host system actually has more than one physical CPU, but you can
still emulate multiple CPUs nervertheless even on a uniprocessor system
(and you might even achieve a small performance benefit when you do).
There is little point, however, in specifying <tt>NUMCPU</tt> greater
than 1 unless your guest operating system (running under Hercules) is
actually able to support multiple CPUs (and if you do not actually need
multiprocessor emulation, then setting <tt>MAX_CPU_ENGINES</tt> to 1 at
compile time might even produce a slight performance advantage too).
<p>
<a name="NUMVEC"></a>
<dt><code>NUMVEC &nbsp; <em>nn</em></code>
<dd><p>
specifies the number of emulated vector facilities. Default is one per
CPU. Only available by default in ESA/390 mode.
<p>
<a name="OSTAILOR"></a>
<dt><code>OSTAILOR &nbsp; OS/390 &#124; z/OS &#124;
VM &#124; VSE &#124; z/VSE &#124; LINUX &#124; OpenSolaris &#124; QUIET &#124; NULL</code>
<dd><p>
specifies the intended operating system. The effect of this
parameter is to reduce control panel message traffic by
selectively suppressing trace messages for program checks
which are considered normal in the specified environment.
<code>QUIET</code> discards all exception messages.
<code>NULL</code> allows all exception messages to be logged.
<p>
Optionally prefix any value except <code>QUIET</code> or
<code>NULL</code> with '+' to cause the suppressions for that
environment to be combined (added) to those already specified,
or with '-' to remove such suppressions (i.e. to allow them).
<p>
If the <code>OSTAILOR</code>
statement is omitted, exception messages for program checks
10, 11, 16, and 1C are suppressed.
<p>
Use the <code>ostailor</code> or <code>pgmtrace</code> panel
commands to display or alter the current settings.
<p>
<a name="PANRATE"></a>
<dt><code>PANRATE &nbsp; <u>SLOW</u> &#124; FAST &#124; <em>nn</em></code>
<dd><p>
specifies the panel refresh rate, in milliseconds between refreshes. SLOW
is the same as 500, and FAST is the same as 50. A value less than the
Linux system clock tick interval (10 on Intel, 1 on Alpha), or more than
5000, will be rejected. SLOW is the default.
<p>
<a name="PANTITLE"></a>
<dt><code>PANTITLE &nbsp; <em>"title-string"</em></code>
<dd><p>
specifies an optional console window title-bar string to be used
in place of the default supplied by the windowing system. If the value
contains any blanks it must be enclosed within double-quotes.
<p>
This option allows one to distinguish between different Hercules
sessions when running more than one instance of Hercules on the same
machine.
<p>
This option takes effect only when the Hercules console is displayed
on an xterm terminal (commonly used on Unix systems), or
in a Windows command prompt window.
Note that this option has no effect when Hercules is run under control
of the Hercules GUI since Hercules's console window is hidden in favor
of using the GUI's window instead.
<p>
<a name="PGMPRDOS"></a>
<dt><code>PGMPRDOS &nbsp; <u>RESTRICTED</u> &#124; LICENSED</code>
<dd><p>
specifies whether or not Hercules will run licensed program product ESA
or z/Architecture operating systems. If <code>RESTRICTED</code> is
specified, Hercules will stop all CPUs when a licensed program product
operating system is detected. Specify
<code>LICENSED</code> to allow these operating systems to run normally.
This parameter has no effect on Linux/390, Linux for z/Series, or any
370-mode OS.
<p>
<p class="warning">
<b>NOTE: &nbsp;It is <u>YOUR</u> responsibility to comply with
the terms of the license for the operating system you intend to run on
Hercules. If you specify LICENSED and run a licensed operating system in
violation of that license, then don't come after the Hercules developers
when the vendor sends his lawyers after you.</b>
<p>
<code>RESTRICTED</code> is the default. Specifying
<code>LICENSED</code> will produce a message when a licensed operating
system is detected to remind you of your responsibility to comply with
software license terms.
<p>
<a name="PLANT"></a>
<dt><code>PLANT &nbsp; <em>name</em></code>
<dd><p>
specifies the PLANT name returned by the STSI instruction. The default is
<code>ZZ</code>.
<p>
<a name="SCSIMOUNT"></a>
<dt><code>SCSIMOUNT &nbsp; <u>NO</u> &#124; YES &#124; <em>nn</em></code>
<dd><p>
specifies whether automatic detection of SCSI tape mounts are to be
enabled or not.
<p>
Specifying <code>NO</code> or 0 seconds (the default) indicates
the option is disabled, forcing all SCSI tape mounts to be done
manually via an appropriate <code>devinit</code> command.
<p>
A value from 1 to 99 seconds inclusive enables the option
and causes periodic queries of the SCSI tape drive to automatically
detect when a new tape is mounted. Specifying <code>YES</code>&nbsp;
is the same as specifying 5 seconds.
<p>
The <code>scsimount</code> panel command may also be used to display
and/or modify this value on demand once Hercules has been started. Note
too that the <code>scsimount</code> panel command also lists any mounts
and/or dismounts that may still be pending on the drive, as long as
you've defined your tape drive as a model that has an LCD "display"
(such as a model 3480, 3490 or 3590).
<p>
<i>
<b>Note:</b> &nbsp;enabling this option may cause Hercules to take
longer to shutdown depending on the value specified for this option
as well as how the host operating system (Windows, Linux, etc) and
associated hardware (SCSI adapter) behaves to drive status queries
for drives which do not have any media currently mounted on them.
</i>
<p>
<a name="SHCMDOPT"></a>
<dt><code>SHCMDOPT &nbsp; DISABLE &#124; NODIAG8</code>
<dd><p>
When set to <code>DISABLE</code>, <code>sh</code> (shell) commands are globally disabled, and will result
in an error if entered either directly via the Hercules hardware console or
programmatically via the <a href="#DIAG8CMD">DIAG8CMD</a> interface.
<p>
When set to <code>NODIAG8</code> only the programmatic execution of shell commands via the
the Diagnose 8 interface is disabled, but <code>sh</code> (shell) commands entered directly
via the Hercules hardware console will still work.
<p>
<b>NOTE:</b> &nbsp;<i>"entered directly via the Hercules hardware console"</i>
also pertains to both commands entered via the
<a href="#HTTPROOT">HTTP server facility</a>
as well as commands entered via
<a href="hercinst.html#RCFILE">.rc "run command"</a> scripts.
<p>
<a name="SHOWDVOL1"></a>
<dt><code>SHOWDVOL1 &nbsp; [ <u>NO</u> &#124; YES &#124; ONLY ]</code>
<dd><p>
Indicates whether to show the dasd VOL1 labels (volser) in the device list
display. 'YES' shows the volser in addition to the usual filename, whereas
'NO' shows the device list in a traditional filename only format. The 'ONLY'
option shows only the volser; the filename is not shown at all. The default
is 'NO', which results in a traditional device list display. This statement
has no effect when no operand is given and instead simply echos the current
setting to the console.
<p>
<i>
<b>Note:</b> &nbsp;support for this command/statement must be specifically
generated by enabling the </i><code>#define OPTION_SHOWDVOL1</code><i>
statement in source header 'featall.h' and then rebuilding Hercules.
</i>
<p>
<a name="SHRDPORT"></a>
<dt><code>SHRDPORT &nbsp; <em>nnnn</em></code>
<dd><p>
specifies the port number (in decimal) on which the <a href="shared.html">Shared Device server</a>
will listen. Specifying SHRDPORT will allow other Hercules instances
to access devices on this instance. (Currently only DASD devices may
be shared). By default, the other Hercules instances (clients) will
use port 3990. If you specify a different port number, then you will
have to specify this port number on the device statement for the other
Hercules clients.
If no SHRDPORT statement is present then the Shared Device server thread
will not be activated.<br>
<p>
<a name="SRVPRIO"></a>
<dt><code>SRVPRIO &nbsp; <em>nn</em></code>
<dd><p>
specifies the priority of the server threads. The default value is 4.
See <a href="#thread_priorities">"Thread Priorities"</a>
below for more information.
<p>
<i><b>Caution:</b> &nbsp;SRVPRIO should not have a higher dispatching
priority than the TOD Clock and timer thread.</i>
<p>
<a name="SYSEPOCH"></a>
<dt><code>SYSEPOCH &nbsp; <em>yyyy</em> [&plusmn;<em>years</em>]</code>
<dd><p>
specifies the base date for the TOD clock. Use the default value
(<code>1900</code>) for all systems except OS/360. Use <code>1960</code>
for OS/360. Values other than these were formerly used to offset the
TOD clock by a number of years to move the date before the year 2000 for
non-Y2K-compliant operating systems. This use is deprecated, and support
will be removed in a future release; at that time, only values of
<code>1900</code> or <code>1960</code> will be accepted. Other values
will produce a warning message with the equivalent values to specify in
the SYSEPOCH statement.<br>
An optional year offset may be specified, and will be treated as though
it had been specified on a <a href="#YROFFSET"><code>YROFFSET</code></a>
statement.
<p>
<a name="TIMERINT"></a>
<dt><code>TIMERINT &nbsp; DEFAULT &#124; <em>nnnn</em></code>
<dd><p>
specifies the internal timers update interval, in microseconds. This
parameter specifies how frequently Hercules's internal timers-update thread
updates the TOD Clock, CPU Timer, and other architectural related
clock/timer values. The default interval is 50 microseconds, which
strikes a reasonable balance between clock accuracy and overall host
performance. The minimum allowed value is 1 microsecond and the maximum
is 1000000 microseconds (i.e. one second).
<p>
<i><b>Caution:</b> &nbsp;While a lower TIMERINT value may help
increase the accuracy of your guest's TOD Clock and CPU Timer values,
it could also have a severe negative impact on the overall performance
of your host operating system. This is especially true when a low TIMERINT
value is coupled with a high <a href="#HERCPRIO">HERCPRIO</a> and
<a href="#TODPRIO">TODPRIO</a> priority setting. Exercise extreme caution
when choosing your desired TIMERINT in relationship to your chosen
<a href="#HERCPRIO">HERCPRIO</a> and <a href="#TODPRIO">TODPRIO</a>
priority settings.
</i>
<p>
<a name="TODDRAG"></a>
<dt><code>TODDRAG &nbsp; <em>n.nn</em></code>
<dd><p>
specifies the TOD clock drag factor. This parameter can be used
to slow down or speed up the TOD clock by a factor of <em>nn</em>.
A significant slowdown can improve the performance of some operating
systems which consume significant amounts of CPU time processing
timer interrupts.
A drag factor of 2.0 slows down the clock by 50%. A drag factor of
0.5 doubles the speed of the clock. A drag factor of 1.01 slows
down the clock by 1%, and 0.99 speeds up the clock by 1%.
<p>
<a name="TODPRIO"></a>
<dt><code>TODPRIO &nbsp; <em>nn</em></code>
<dd><p>
specifies the priority of the TOD Clock and timer thread. The
default value is -20. See
<a href="#thread_priorities">"Thread Priorities"</a>
below for more information.
<p>
<i><b>Caution:</b> &nbsp;TODPRIO should be given a dispatching
priority equal to or higher than any other thread within Hercules.</i>
<p>
<a name="TRACEOPT"></a>
<dt><code>TRACEOPT &nbsp; <u>TRADITIONAL</u> &#124; REGSFIRST &#124; NOREGS</code>
<dd><p>
sets the Hercules instruction tracing display option.
<code>TRADITIONAL</code> (the default), displays the registers following
the instruction about to be executed such that pressing enter (to execute
the displayed instruction) then shows the next instruction to be executed
followed by the updated registers display.
<p>
<code>REGSFIRST</code> displays the current register contents followed by
the instruction about to be executed such that pressing enter (to execute
the displayed instruction) then shows the updated registers followed by
the next instruction to be executed.
<p>
<code>NOREGS</code> suppresses the registers display altogether
and shows just the instruction to be executed.
<p>
In addition to the <code>TRACEOPT</code> configuration file statement
there is also a corresponding <code>traceopt</code> panel command to
dynamically display and/or update the current setting at any time.
<p>
<a name="TZOFFSET"></a>
<dt><code>TZOFFSET &nbsp; &plusmn;<em>hhmm</em></code>
<dd><p>
specifies the hours and minutes by which the TOD clock will
be offset from the current system time. For GMT, use the
default value (0000). For timezones west of Greenwich, specify
a negative value (example: <code>-0500</code> for US Eastern Standard
Time, <code>-0800</code> for US Pacific Standard Time).
For timezones east of Greenwich, specify a positive value
(example: <code>+0100</code> for Central European Time,
<code>+0930</code> for South Australian Time).
<p>
<a name="XPNDSIZE"></a>
<dt><code>XPNDSIZE &nbsp; <em>nnnn</em> &#124;
<em>nnn</em>M &#124;
<em>nnn</em>G &#124;
<em>nnn</em>T &#124;
<em>nnn</em>P &#124;
<em>nnn</em>E</code>
<dd><p>
specifies the expanded storage size in megabytes, where
<code><em>nnnn</em></code> is a decimal number. Or,
<code><em>nnnM</em></code> &nbsp;where <code><em>M</em></code>&nbsp;
is K - Kilobytes, M - Megabytes, G - Gigabytes, T - Terabytes,
P - Petabytes, E - Exabytes.
<p>
Storage sizes not on a 1M boundary are rounded up to the next 1M
boundary. The lower limit and default is 0.
<p>
<b>Notes:</b>
<ol><p><li>
The actual upper limit is determined by your host system's
architecture and operating system, the guest operating system, and
the amount of physical memory and available paging space. The total
of mainsize and xpndsize on host systems with a 32-bit architecture
will be limited to less than 4G; host systems with a 64-bit
architecture will be limited to less than 16E.
</li><p><li>
Use of storage sizes greater than supported by the guest operating
system may generate incorrect results or error conditions within the
guest operating system.
</li></ol>
<p>
<a name="YROFFSET"></a>
<dt><code>YROFFSET &nbsp; &plusmn;<em>years</em></code>
<dd><p>
specifies a number of years to offset the TOD clock from the actual
date. Positive numbers will move the clock forward in time, while
negative numbers will move it backward. A common value for
non-Y2K-compliant operating systems is <code>YROFFSET -28</code>, which
has the advantage that the day of the week and the presence or absence
of February 29 is the same as the current year. This value may not be
specified as greater than &plusmn;142 years, the total range of the TOD
clock. Specifying a value that causes the computed TOD clock year to be
earlier than the value of <a href="#SYSEPOCH"><code>SYSEPOCH</code></a>
or more than 142 years later than that value will produce unexpected
results.
<p>
</dl>
<p>
A comment preceded by a &#035; sign may be appended to any system
parameter statement.
<p>
<hr><!-- ---------------------------------------------------------------------------- -->
<a name="subs"></a>
<h3>Symbol substitutions</h3></a>
<p>
In configuration and device statements, as well as in panel commands and OAT files,
symbols may be substituted for text.
<h4>Syntax</h4>
<p>
To substitute symbol <em>symbol</em> with its contents, the symbol should be enclosed
within parenthesis and preceded by a $ sign. For example, if symbol <em>FOO</em> contains
the text string <em>&quot;BAR&quot;</em> then <em>$(FOO)</em> will be substituted with the
string <em>&quot;BAR&quot</em>;. Symbol names are case sensitive.
<h5>Example</h5><code><pre>
DEFSYM TAPEDIR &quot;/home/hercules/tapes&quot;
...
0380 3420 $(TAPEDIR)/scratch.aws
...</pre></code>
<p>
In this example, device 0380 will be a 3420 loaded with the AWS tape file in /home/hercules/tapes/scratch.aws
<h4>Special symbols</h4>
<h5>Device group symbols</h5>
<p>
When multiple devices are defined with a single device definition statement, then the symbols<P>
<blockquote>
<TABLE BORDER=0>
<ul compact>
<TR><TD><LI>&nbsp; CUU &nbsp; </TD><TD> &nbsp; (3 digits device number, upper case hexadecimal digits)</TD></TR>
<TR><TD><LI>&nbsp; CCUU &nbsp; </TD><TD> &nbsp; (4 digits device number, upper case hexadecimal digits)</TD></TR>
<TR><TD><LI>&nbsp; DEVN &nbsp; </TD><TD> &nbsp; (4 digits device number, upper case hexadecimal digits)</TD></TR>
</ul>
</TABLE>
</blockquote>
<p>
are defined to contain for each device the relevant device address. For example:
<p>
<code><pre>
0200,0201 3340 /home/hercules/dasds/myvols.$(CUU)
</pre></code>
<p>
will define two 3340 packs, with device 0200 being loaded with the file myvols.200 and
device 0201 defined with myvols.201.
<h5>Environment variables</h5>
<p>
If a symbol is not explicitly defined by a DEFSYM statement and an environment
variable by the same name exists, the string contents of that environment variable
will be used for substitution.
<h5>Undefined symbols</h5>
<p>
If a symbol is not defined by an explicit DEFSYM, is not an automatically generated symbol
and is not an environment variable, an empty string will be substituted.
<h4>Escaping substitution, recursion</h4>
<p>
To be able to specify the '$(' string without incurring substitution, an additional '$' sign
should be used. For example, $$(FOO) will not be substituted. If substitution is required but
the preceding text is to contain a '$' sign as the very last character, then $$$(FOO) should be
specified. Thus, if symbol FOO contains &quot;BAR&quot;, then $$(FOO) will remain &quot;$$(FOO)&quot; while $$$(FOO)
will become &quot;$BAR&quot;.
<p>
Substitution is <i>not</i> recursive (only one substitution pass is made).
<p>
<hr><!-- ---------------------------------------------------------------------------- -->
<a name="ENHSYMINC"></a>
<h3>Enhanced symbol substitutions</h3></a>
<p>
Enhanced symbol substitution differs from the above normal symbol substitution
in several very important ways:
<p>
First, the syntax is different. Enhanced substitution symbol names are specified
using <code>${var}</code> (dollar + brace) rather than <code>$(var)</code>
(dollar + parenthesis).
<p>
Second, the enhanced syntax supports specifying a default value that is to be used
instead whenever the name symbol is otherwise not defined. The default value is
placed within the opening and closing braces just as the symbol name is, but
separated from it by either a single equal sign '<code>=</code>' or a
colon-equal-sign '<code>:=</code>'.
<p>
For example, specifying "<code>${DASD_PATH=dasd/}</code>" in your configuration
file requests that the value of the "DASD_PATH" symbol or environment variable be
substituted, or, if the variable is undefined, to use the value "<code>dasd/</code>"
instead. If no default value is specified then an empty string is used instead.
<p>
Finally, enhanced symbol substitution occurs only from host defined environment
variables and <i>not</i> from any identically named <code>DEFSYM</code> symbol
should one exist. For example, if environment variable 'FOO' is defined with the
value "bar", then the configuration file statement "<code>DEFSYM FOO myfoo</code>"
followed immediately by the statement "<code>${FOO}</code>" causes the value
"<code>bar</code>" to be substituted and <i>not</i> '<code>myfoo</code>' as might
otherwise be believed, whereas the statement "<code>$(FOO)</code>", since it is
a normal symbol substitution sequence <i>does</i> get replaced with "<code>myfoo</code>"
(since that was the value defined to it via the preceding <code>DEFSYM</code>
statement).
<p>
In other words each symbol substitution technique is supported completely separately
from one another. <code>DEFSYM</code> allows one to define/undefine/use private (internally
defined) symbols separate from the host operating system's environment variable pool,
whereas the enhanced symbol substitution does not and instead only allows read-only
access to the host's environment variable pool with no support for modifying an already
defined symbol (environment variable) but a nonethless convenient means of defining
a default value to be used should the specified host environment variable be currently
undefined.
<p>
Further note that symbol names, being the names of environment variables, are subject
to whatever case sensitivity or case insensitivity that the host operating system
happens to enforce/allow. On Windows, environment variables are not case sensitive, whereas on other
operating systems they may be. Thus "<code>${FOO}</code>", "<code>${foo}</code>",
"<code>${Foo}</code>", etc, all cause the same value to be substituted on Windows,
whereas the <code>DEFSYM</code> symbols <code>$(FOO)</code> and <code>$(foo)</code>,
being two completely different and unique symbols, could be substituted with two
completely different values (since <code>DEFSYM</code> <b><i>is</i></b>
case sensitive across <i>all</i> supported platforms, <i>including</i> Windows).
<p>
<h4>Syntax</h4>
<p>
To substitute symbol <em>symbol</em> with the current environment variable value,
the symbol should be enclosed within braces and preceded by a $ sign. For example,
if an environment variable named <code>FOO</code> holds the value "BAR", then
<code>${FOO}</code> will be substituted with the string "BAR". If the environment variable
"FOO" is not defined then a null (empty) string is substituted instead.
<p>
If the string "<code>${FOO:=myfoo}</code>" is used instead, then the value "BAR" will still be
substituted if the value "BAR" was indeed previously assigned to FOO, but will be
substituted with the value "<code>myfoo</code>" instead if the environment variable
FOO is currently undefined.
<p>
Note too that the default value is a literal
string and no substitution is applied to it. Thus attempting to use the syntax
"<code>${foo=${bar}}</code>" will <i>not</i> yield the expected results. It will
<i>not</i> be substituted with the currently defined value of the "bar" environment
variable, but rather will <i>always</i> be substituted with the literal string
"<code>${bar</code>" followed immediately by the literal character '<code>}</code>'.
<p>
Symbol names (environment variable names) are not case sensitive on Windows whereas
they might be on other host operating systems.
<p>
<hr><!-- ---------------------------------------------------------------------------- -->
<a name="process_and_thread_priorities"></a>
<h3>Process and Thread Priorities</h3>
<p><br>
<a name="process_priorities"></a>
<h4>Process Priorities</h4>
<P>
<B>Note:</B> Under Linux, a process is a thread and
<a href="#thread_priorities">thread priority</a> information
applies instead.
<P>
For Windows, the following conversions are used for translating Unix
process priorities to Windows process priority classes:
<P>
<BR>
<table frame="VOID" rules="NONE" cellpadding="0" cellspacing="0">
<TR>
<TH ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">Unix<br>Priority</TH>
<TH ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%"><BR></TH>
<TH ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Windows Process<br>Priority Class</TH>
<TH ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%"><br>Meaning</TH>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-20 to -16</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Real-time</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process that has the highest possible priority. The threads of the process
preempt the threads of all other processes, including operating system processes
performing important tasks. For example, a real-time process that executes for
more than a very brief interval can cause disk caches not to flush or cause
the mouse to be unresponsive.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-15 to -9</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">High</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process that performs time-critical tasks that must be executed immediately.
The threads of the process preempt the threads of normal or idle priority class
processes. An example is the Task List, which must respond quickly when called
by the user, regardless of the load on the operating system. Use extreme care
when using the high-priority class, because a high-priority class application
can use nearly all available CPU time.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-8 to -1</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Above Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process that has priority above the Normal class but below the High class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">0 to 7</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process with no special scheduling needs.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">8 to 14</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Below Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process that has priority above the Idle class but below the Normal class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">15 to 20</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Idle</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Process whose threads run only when the system is idle. The threads of the
process are preempted by the threads of any process running in a higher priority
class. An example is a screen saver. The idle-priority class is inherited by
child processes.
</TD>
</TR>
</TABLE>
<p><br>
<blockquote>
<p>
<i>
<b>Caution:</b> &nbsp;On Windows, the value you choose for your
<a href="#HERCPRIO">Process Priority</a>
has a direct impact on how your
<a href="#thread_priorities">Thread Priorities</a> are interpreted!
You should never modify one without understanding what impact your doing so
might have on the other!
</i>
</blockquote>
<p><br>
<a name="thread_priorities"></a>
<h4>Thread Priorities</h4>
<P>
On a Linux/Unix host, Hercules needs to be a setuid root
program to allow it to reset its dispatching priority to a high
(negative) value
(i.e., <code>chown root.root hercules; chmod +s hercules</code>).
<P>
For Windows, the following conversions are used for translating
Linux/Unix thread priorities to Windows thread priorities:
<P><BR>
<table frame="VOID" rules="NONE" cellpadding="0" cellspacing="0">
<TR>
<TH ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">Unix<br>Priority</TH>
<TH ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%"><BR></TH>
<TH ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Windows<br>Thread Priority</TH>
<TH ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%"><br>Meaning</TH>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-20 to -16</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Time Critical</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Base priority of 15 for Idle, Below Normal, Normal, Above Normal, or High
class processes, and a base priority of 31 for Realtime class processes.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-15 to -9</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Highest</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Priority 2 points above the priority class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">-8 to -1</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Above Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Priority 1 point above the priority class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">0 to 7</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Normal priority for the priority class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">8 to 14</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Below Normal</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Priority 1 point below the priority class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">15 to 19</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Lowest</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Priority 2 points below the priority class.
</TD>
</TR>
<TR> <!-- ============================================================================ -->
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">&nbsp;</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">&nbsp;</TD>
</TR>
<TR>
<TD ALIGN="RIGHT" VALIGN="BASELINE" WIDTH="11%">20</TD>
<TD ALIGN="CENTER" VALIGN="BASELINE" WIDTH="6%">&nbsp;</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="20%">Idle</TD>
<TD ALIGN="LEFT" VALIGN="BASELINE" WIDTH="63%">
Base priority of 1 for Idle, Below Normal, Normal, Above Normal, or High
class processes, and a base priority of 16 for Realtime class processes.
</TD>
</TR>
</TABLE>
<p><br>
<blockquote>
<p>
<i>
<b>Caution:</b> &nbsp;On Windows, your Thread Priority is interpreted
differently based on your chosen <a href="#HERCPRIO">Process Priority</a> setting!
You should never modify your Thread Priority settings without first reviewing your
chosen <a href="#HERCPRIO">Process Priority</a> setting!
</i>
</blockquote>
<p>
<hr><!-- ---------------------------------------------------------------------------- -->
<a name="device_stmts"></a>
<h3>Device statements</h3>
<p>
The remaining statements in the configuration file are device statements.
There must be one device statement for each I/O device or group of
identical I/O devices. The format of the device statement is:
<p>
<blockquote>
<code><em>devnum(s) &nbsp; devtype</em> &nbsp; [ <em>arguments</em> ] &nbsp; [ <em># comments...</em> ] </code>
</blockquote>
<p>
where the generic syntax for device numbers is &nbsp;
<code>[n:]CCUU[,CCUU][-CCUU][.nn][...]</code> &nbsp;
as explained below:
<blockquote>
<dl> <!-- begin Device statements -->
<a name="devnums"></a>
<dt><code><em>devnum(s)</em></code>
<dd><p>
is either a single <em>devnum</em>, a range of <em>devnums</em> (separated by a '-' (dash)),
a count of <em>devnums</em> (separated by a '.' (dot/period/stop)), or a comma separated
list of <em>devnums</em>. Examples would be 200-210 or 0300.10 or 0400,0403 or 0100,0110-011F.
<p>
All devices defined when <em>devnums</em> specifies more than one device
have identical characteristics (except for the device number itself).
All devices defined as a group must be defined on a single channel.
A channel is defined as a contiguous group of 256 (or hexadecimal 100) devices.
0010 and 0020 are on the same channels. 0100 and 0210 are not.
<p>
See <em>devnum</em> immediately below for an explanation of how each device number is specified.
<p />
The 4 special subtitution symbols CUU, CCUU, cuu and ccuu are also defined for each
device in a device group. See <a href="#subs">substitutions</a> for details.
<p>
<dt><code><em>devnum</em></code>
<dd><p>
is either a 1 to 4 digit hexadecimal number in the range 0000 to FFFF
for ESA/390, or 0000 to 0FFF for S/370. The device number uniquely
identifies each device to the operating system.
<p>
<dt><code><em>Channel Set / Logical Channel Subsystem</em></code>
<dd><p>
An optional Channel Set or Logical Channel Subsystem Identification can be
specified for a device number or group of devices. The Identification
number is specified at the beginning of the definition, followed by a ':'
character. For example :<p>
1:0400-040F 3270<p>
defines 3270 devices 400 to 40F to be on S/370 Channel Set 1 or on S/390
or z/Architecture Logical Channel Subsystem # 1.<p>
Since each Logical Channel Subsystem defines its own device numbering space,
care should be taken in S/370 mode as to define a coherent set of device
numbers.<p>
Not all S/390 or z/Architecture operating systems support Multiple Logical
Channel Subsystems (this feature was introduced with the z9-109).<p>
If no Channel Set or Logical Channel Subsystem Identification is specified,
then it is assumed to be 0.
<p>
<dt><code><em>devtype</em></code>
<dd><p>
is the device type. Valid device types are shown in the
<a href="#device_types_table">table</a> just below.
<p>
<dt><code><em>arguments</em></code>
<dd><p>
is a list of parameters whose meaning depends on the device type.
The arguments required for each class of device are shown further
below.
<p>
<dt><code><em># comments...</em></code>
<dd><p>
A comment preceded by a &#035; sign may be appended to any device
definition statement.
<p>
</dl> <!-- end Device statements -->
</blockquote>
<p><br>
<a name="device_types_table"></a>
<table width=85%>
<tr>
<td width=15%>
&nbsp;
</td>
<td>
<table border=1 cellpadding=8>
<tr>
<th colspan=3><br><big>Supported Device Types</big><p></th>
</tr>
<tr><th>Device type</th>
<th>Description</th>
<th>Emulated by</th>
</tr>
<tr><td>3270, 3287</td>
<td><a href="#loc3270">Local non-SNA 3270 display or printer</a></td>
<td>TN3270 client connection</td>
</tr>
<tr><td>SYSG</td>
<td><a href="#SYSG">Integrated 3270 console</a></td>
<td>TN3270 client connection</td>
</tr>
<tr><td>1052, 3215</td>
<td><a href="#conprkb">Console printer-keyboards</a></td>
<td>Telnet client connection</td>
</tr>
<tr><td>1052-C, 3215-C</td>
<td><a href="#consysc">Integrated console printer-keyboards</a></td>
<td>Integrated on Hercules console</td>
</tr>
<tr><td>1442, 2501, 3505</td>
<td><a href="#cardrdr">Card readers</a></td>
<td>Disk file(s) (ASCII or EBCDIC)</td>
</tr>
<tr><td>3525</td>
<td><a href="#cardpch">Card punch</a></td>
<td>Disk file (ASCII or EBCDIC)</td>
</tr>
<tr><td>1403, 3211</td>
<td><a href="#printer">Line printers</a></td>
<td>Disk file (ASCII)</td>
</tr>
<tr><td>3410, 3420, 3422, 3430, 3480, 3490, 3590, 9347, 8809</td>
<td><a href="#tapedev">Tape drives</a></td>
<td>Disk file, CDROM, or SCSI tape</td>
</tr>
<tr>
<td>
<a href="#3088">
3088
</a>
</td>
<td>
Channel-to-Channel Adapter device
</td>
<td>
<a href="#CTCT">"CTCT" driver</a>
or
<a href="#CTCE">"CTCE" driver</a>
</td>
</tr>
<tr>
<td>
(( <a href="#CTCI">CTCI</a> ))
</td>
<td>
Channel-to-Channel link to host TCP/IP stack
</td>
<td>
<a href="#CTCI">"CTCI" TUN/TAP Driver</a>
</td>
</tr>
<tr>
<td>
(( <a href="#LCS">LCS</a> ))
</td>
<td>
IBM 2216 router, IBM 3172 running ICP,
IBM 8232 LCS device, LCS3172 driver of a P/390,
IBM Open Systems Adapter (OSA)
</td>
<td>
<a href="#LCS">"LCS" (LAN Channel Station)
<br>TUN/TAP Driver</a>
</td>
</tr>
<tr>
<td>
(( <a href="#PTP">PTP</a> ))
</td>
<td>
MPCPTP/MPCPTP6 Channel to Channel link
</td>
<td>
<a href="#PTP">"PTP" TUN/TAP Driver</a>
</td>
</tr>
<tr>
<td>
(( <a href="#QETH">QETH</a> ))
</td>
<td>
OSA Express IP Layer 2 support only.
Supported only for linux guests.
TAP Adapter must be bridged to a local LAN.
</td>
<td>
<a href="#QETH">"QETH" (OSA/QDIO Ethernet Adapter)
<br>TUN/TAP Driver</a>
</td>
</tr>
<tr><td>3310, 3370, 9332, 9335, 9336, 0671</td>
<td><a href="#fbadasd">FBA direct access storage devices</a></td>
<td>Disk file</td>
</tr>
<tr><td>2305, 2311, 2314, 3330, 3340, 3350, 3375, 3380, 3390, 9345</td>
<td><a href="#ckddasd">CKD direct access storage devices</a></td>
<td>Disk file</td>
</tr>
<tr><td>2703</td>
<td><a href="#comline">Communication Line</a></td>
<td>TCP Socket</td>
</tr>
<tr><td>2703</td>
<td><a href="#remtty">Remote Teletype</a></td>
<td>TCP Socket</td>
</tr>
</table>
</td>
</tr>
</table>
<p><br>
<h4>Arguments required for each device type</h4>
<dl> <!-- begin Arguments for each device type -->
<p>
<a name="3270"></a>
<a name="loc3270"></a>
<dt><em>Local non-SNA 3270 devices</em>
<dd><p>
There are no required arguments for this particular device type, but
there are however several optional arguments which are discussed below.
<p>
To use this device, a tn3270 client must connect to the host machine
via the port number specified on the <a href="#CNSLPORT">CNSLPORT</a>
statement. A valid tn3270 device type, such as IBM-3278, must be used.
<p>
If your tn3270 client software allows you to specify a device type suffix
(e.g. <code>IBM-3278@001F</code> ), then you can use the suffix to connect
to that specific device number, if eligible. If no suffix is specified,
then your client will be connected to the first available 3270 device for
which it is eligible, if any.
<p>
If you specify a specific terminal device address (via the device type
suffix of your tn3270 client software), then you must be eligible to connect
at that device address or your connection is immediately rejected; an
alternative terminal device for which you <i>might</i> be eligible is
<i>not</i> automatically selected instead.
<p>
Optional arguments:
<p>
<dl>
<a name="loc3270group"></a>
<dt><code><em>groupname</em></code>
<dd><p>
If a terminal group name is given on the device statement, a device type
suffix with this group name can be used to indicate that a device in this
group is to be used. If a group name is specified as a terminal type suffix
(e.g. <code>IBM-3278@GROUPNAME</code> ) and there are no devices defined
for that group (or there are no more available devices remaining in that
group), then the connection is rejected. If no group name is specified
as a terminal type suffix, then the connection will only be eligible for
any terminal devices which do <i>not</i> have a group name specified on
their device statements. The terminal group name, if specified, should
be 1 to 8 alphanumeric characters, the first character being alphabetic,
and it should <i>not</i> be a hexadecimal number. Upper and lower case
letters in the group name are considered to be equivalent.
<p>
<a name="loc3270ipaddr"></a>
<dt><code><em>ipaddr</em> [ <em>mask</em> ]</code>
<dd><p>
The optional IP address and optional subnet mask specify the ip address(es)
of which client(s) are allowed to connect at the device address identified
by the device statement on which they appear. This provides an alternative
and/or additional means of specifying to which device(s) a client tn3270
session may, or should, connect.
<p>
If the IP address of the tn3270 client trying to connect, when 'and'ed with
the optional subnet mask (which defaults to 255.255.255.255 if not specified),
matches the IP address entered on the device statement, then the client
is eligible to connect at that device address. Otherwise the client is
ineligible to connect at that address and then next available device, if
any, for which the client is eligible to connect (if any) is selected instead.
<p>
If no permissible terminal devices remain (i.e. terminal devices for which
the client is eligible to connect), or there are no more available terminal
devices remaining, then the client connection is rejected.
<p>
The optional IP address and subnet mask may also be specified in conjunction
with the previously mentioned terminal group argument, but the terminal group
argument, if specified, must be specified <i>ahead of</i> (i.e. before) the
optional ip address and subnet mask arguments. To specify an IP address and
subnet mask without also specifying a terminal group, simply use '*' as the
group name instead.
<p>
If an IP address / subnet mask are <i>not</i> specified, then <i>any</i>
client tn3270 session is allowed to connect to the device (provided they are also
a member of the specified terminal group, if any).
<p>
The terminal group name argument, if specified, always takes precedence over
any optional ip address and subnet mask which may also be specified.
<p>
</dl>
To summarize, the device number suffix always takes precedence over any group name
which may also be specified, and any group name, if specified, always takes precedence
over any ip address / subnet mask value which may also be specified.
<p>
<hr width="50%"><p>
<a name="SYSG"></a>
<dt><em>Integrated 3270 console device</em>
<dd><p>
The integrated 3270 (SYSG) console is similar to a <a href="#loc3270">local non-SNA
3270</a> device, except that it is not addressed by subchannel number and it is
supported only by certain system control programs. The SYSG console is defined
like a 3270 device except that the device type is SYSG and the device number is
ignored. Only one SYSG console can be defined in a configuration.
<p>
Use tn3270 client software to connect to the SYSG console device via the port number
specified on the <a href="#CNSLPORT">CNSLPORT</a> statement, just as you would connect
to a regular local non-SNA 3270 device.
<p>
The SYSG console configuration statement recognizes optional arguments which specify
<a href="#loc3270group">group name</a> and <a href="#loc3270ipaddr">IP address</a>
in the same way as previously described for a <a href="#loc3270">local non-SNA
3270</a> device. These optional arguments provide a means to ensure that a given
tn3270 client can connect directly to the SYSG console. If the group name and IP
address arguments are not specified, then the SYSG console is considered to be a
member of the general pool of devices eligible for connection to any incoming
tn3270 client.
<p>
<hr width="50%"><p>
<a name="consysc"></a>
<dt><em>Integrated Console printer-keyboard devices</em>
<dd><p>
There is one optional argument which is the command prefix
for sending input to the device. The default command prefix is '/'.
<p><em>
<b>Note:</b> There is no restriction on the character you can select.
If you select a command character that is the first character of a panel
command, you will not be able to use that command.
</em>
<p>
To send a logon command to a 1052-C or 3215-C enter /logon on the Hercules console.
<p>
All integrated devices must use a different command prefix.
<p>
<hr width="50%"><p>
<a name="conprkb"></a>
<dt><em>Console printer-keyboard devices</em>
<dd><p>
There are no required arguments for this particular device type, but
there are however several optional arguments discussed below.
<p>
To use this device, a telnet client must connect to the host machine
via the port number specified on the <a href="#CNSLPORT">CNSLPORT</a> statement.
<p>
If your telnet client software allows you to specify a device type suffix
(for example: <code>ansi@0009</code> ), then you can use that suffix to specify
the specific 1052 or 3215 device to which you wish to connect. If you do not
specify a suffix in your telnet client software (or your software does not
allow it), then your client will be connected to the first available 1052 or
3215 device for which it is eligible.
<p>
An optional <code>noprompt</code> argument may be specified on the device
statement to cause suppression of the "Enter input for console device nnnn"
prompt message which is otherwise normally issued to the device whenever
the system is awaiting input on that device.
<p>
Additionally, a terminal group name, ip address and subnet mask may all also
be optionally specified in the exact same manner as discussed in the previous
<a href="#loc3270">Local non-SNA 3270 devices</a> section with the exception
that the "noprompt" option, if specified, must precede the other arguments.
<p>
<hr width="50%"><p>
<a name="1442"></a>
<a name="3505"></a>
<a name="cardrdr"></a>
<dt><em>Card reader devices</em>
<dd><p>
The argument specifies a list of file names containing card images.
Additional arguments may be specified after the file names:
<p>
<dl>
<dt><code>sockdev</code>
<dd><p>
indicates the card reader is a socket device wherein the
filename is actually a socket specification instead of a
device filename. When used, there must only be one filename
specified in the form: <code>port</code> or <code>host:port</code>
or <code>sockpath/sockname</code>. The device then accepts
remote connections on the given TCP/IP port or Unix Domain
Socket, and reads data from the socket instead of from a device
file. This allows automatic remote submission of card reader
data. See the <a href="hercrdr.html">Hercules Socket Reader</a>
page for more details.
<p>
<dt><code>eof</code>
<dd><p>
specifies that unit exception status is presented after
reading the last card in the file. This option is persistent, and
will remain in effect until the reader is reinitialized with the
<code>intrq</code> option.
<p>
<dt><code>intrq</code>
<dd><p>
specifies that unit check status with intervention required
sense bytes is presented after reading the last card
in the file. This option is persistent, and will remain in
effect until the reader is reinitialized with the <code>eof</code>
option.
<p>
<dt><code>multifile</code>
<dd><p>
specifies, when multiple input files are entered, to
automatically open the next input file and continue reading
whenever EOF is encountered on a given file. If not specified,
then reading stops once EOF is reached on a given file and
an attention interrupt is then required to open and begin
reading the next file.
<p>
<dt><code>ebcdic</code>
<dd><p>
specifies that the file contains fixed length 80-byte EBCDIC
records with no line-end delimiters.
<p>
<dt><code>ascii</code>
<dd><p>
specifies that the file contains variable length lines of
ASCII characters delimited by LF (line feed) sequences or CRLF
(carraige return line feed) sequences at the end of each line.
<p>
If neither EBCDIC nor ASCII is specified, then the device handler
attempts to detect the format of the card image file when the device
is first accessed.
Auto-detection is not supported for socket devices, and the default
is ASCII if sockdev is specified.
<p>
<dt><code>trunc</code>
<dd><p>
specifies, for ASCII files, that lines longer than 80
characters are truncated instead of producing a unit check
error.
<p>
<dt><code>autopad</code>
<dd><p>
specifies, for EBCDIC files, that the file is automatically
padded to a multiple of 80 bytes if necessary.
<p>
</dl>
<p>
<hr width="50%"><p>
<a name="3525"></a>
<a name="cardpch"></a>
<dt><em>Card punch devices</em>
<dd><p>
The argument specifies the name of a file to which the punched
output will be written.
Additional arguments may be specified after the file name:
<p>
<dl>
<dt><code>ascii</code>
<dd><p>
specifies that the file will be written as variable length
lines of ASCII characters delimited by line feeds or
carriage return line feed sequences at the end of each line.
Trailing blanks are removed from each line.
If the <code>ascii</code> argument is not specified, the
file is written as fixed length 80-byte EBCDIC records with
no line-end delimiters.
<p>
<dt><code>crlf</code>
<dd><p>
specifies, for ASCII files, that carriage return line feed
sequences are written at the end of each line.
If the <code>crlf</code> argument is not specified, then
line-feeds only are written at the end of each line.
<p>
<dt><code>noclear</code>
<dd><p>
specifies that the output file will not be cleared to zero
bytes when it is opened.
If the <code>noclear</code> argument is not specified, then
any previous content of the file is destroyed when the file
is opened for output.
<p>
</dl>
<p>
<hr width="50%"><p>
<a name="1403"></a>
<a name="printer"></a>
<dt><em>Line printer devices</em>
<dd><p>
The argument specifies the name of a file to which the printer
output will be written. The output is written in the form of
variable length lines of ASCII characters delimited by line
feeds or by carriage return line feed sequences. Trailing
blanks are removed from each line. Carriage control characters
are translated to blank lines or ASCII form feed characters.
If the file exists it will be overwritten.
<p>
Additional arguments may be specified after the file name:
<p>
<dl>
<dt><code>sockdev</code>
<dd><p>
indicates the line printer is a socket device wherein the
filename is actually a socket specification instead of a
device filename. When used, there must only be one filename
specified in the form: <code>port</code> or <code>host:port</code>.
The device then accepts
remote connections on the given TCP/IP port,
and writes data to the socket instead of to a device
file. This allows automatic remote spooling of line printer
data. The sockdev option is mutually exclusive with all other
printer options (e.g. crlf, etc) and must be specified alone.
<p>
<dt><code>crlf</code>
<dd><p>
specifies, for ASCII files, that carriage return line feed
sequences are written at the end of each line.
If the <code>crlf</code> argument is not specified, then
line-feeds only are written at the end of each line.
<p>
<dt><code>noclear</code>
<dd><p>
specifies that the output file will not be cleared to zero
bytes when it is opened.
If the <code>noclear</code> argument is not specified, then
any previous content of the file is destroyed when the file
is opened for output.
<p>
<dt><code>fcbcheck</code>
<dd><p>
specifies that an attempt to skip to a FCB channel for which no
line number has been set will cause the command to be rejected
with a unit check. This is the default.
<p>
<dt><code>nofcbcheck</code>
<dd><p>
specifies that an attempt to skip to a FCB channel for which no
line number has been set will cause the next line of output to be
printed on the next line on the printer output. The opposite,
<code>fcbcheck</code>, is the default.
<p>
<dt><code>rawcc</code>
<dd><p>
specifies that printer output CCWs are not to be interpreted, but
simply dumped in hex to the printer output file. This is useful for
debugging. Default is to interpret printer CCWs normally.
<p>
<dt><code>fcb=</code>
<dd><p>
specifies an initial FCB image to use for this printer. The argument
must be exactly 26 digits long, and consist of digits from 0 to 9.
The first pair of digits specifies the number of lines on a printed
page. It is followed by 12 pairs of digits which specify, for FCB
channels 1-12, the line number on the page that the FCB channel
corresponds to. Use <code>00</code> to leave the line number unset
for a channel (see <code>fcbcheck</code> above). The default is
<code>fcb=66010713192531374361495561</code>.
<p>
</dl>
<p>
If the filename begins with the vertical bar '&#124;' pipe character,
then it is removed and the remainder of the filename is interpreted as
a command line (the name of a program or batch file followed by any
necessary arguments) to which to "pipe" the printer output to.
This is known as the "print-to-pipe" feature. All printer output
is then sent to the piped program's stdin input, and all of the
piped program's stdout and stderr output is piped back to Hercules
for displaying on the hardware console.
<p>
If the "print-to-pipe" command line contains arguments, then quotes
must be placed around the entire filename string including the
vertical bar, for example:
<pre>
000E 1403 "|/usr/bin/lpr -Phplj" crlf <em>(for Unix)</em>
000E 1403 "|c:\utils\pr -s -PLPT1:" crlf <em>(for Windows)</em>
</pre>
The above example uses the pr program downloaded
from <a href="http://www.atnetsend.net/computing/">
http://www.atnetsend.net/computing/</a>
<p>
If the "print-to-pipe" command line itself contains quotes, then
the command line must be enclosed in apostrophes instead of quotes,
for example:
<pre>
000E 1403 '|"c:\Program Files\My Utils\pr" -s -PLPT1:' crlf
</pre>
<p>
Tim Pinkawa has an example which shows how the print-to-pipe feature
can be used to create output in PDF format:
<a href="http://www.timpinkawa.net/hercules/prtspool.html">
http://www.timpinkawa.net/hercules/prtspool.html</a>
<p>
<hr width="50%"><p>
<a name="3420"></a>
<a name="tapedev"></a>
<dt><em>Tape devices</em>
<dd><p>
Five types of tape emulation are supported (see further below): &nbsp;
<a href="#AWS"><b>AWS</b></a>, &nbsp;
<a href="#HET"><b>HET</b></a>, &nbsp;
<a href="#FAKETAPE"><b>FakeTape</b></a>, &nbsp;
<a href="#OMA"><b>Optical Media Attach (OMA)</b></a>, &nbsp; and &nbsp;
<a href="#SCSI"><b>real SCSI</b></a> .
<p>
The only required parameter is the device filename. All other parameters
are optional and must follow the filename. Use '<b>*</b>' (asterisk) for
the filename to specify an empty (unmounted) tape drive. The specified file,
if other than '<b>*</b>', <i>must</i> exist.
<p>
Additionally, if the file name starts with the '@' character (at sign), the file
really describes a list of tape emulation files to be loaded in succession.
<p>
The syntax of each line is identical to the information that can be
specified after the device type when the options are specified directly
after the device type in the configuration file.
<p>
If the emulation file filename in the file list is the '<b>*</b>' (asterisk)
character, then this specifies a set of options to be applied to <i>all</i>
additional emulation files specified in the file list.
<p>
Parameters are appended in succession. In all cases, if the same parameter is
specified more than once, the last instance takes precedence.
<p>
Therefore, it is possible to specify a set of parameters in the base configuration
file, another set on a '*' line, and another set for each individual line.
Parameters are then appended in that order: options specified on the base device
statement itself first, followed by those options specified on the '*' statement,
and finally those specified on each individual file list statement last. <i>A
<b>SCSI tape</b> device should <b>not</b> be given in a file list.</i>
<p>
Refer to the distributed source-code's "<b>README.TAPE</b>" document for
additional information regarding system and application programming for tape
devices and instructions regarding use of the emulated <b>ACF</b> (Automatic
Cartridge Feeder) and <a href="#AUTOMOUNT">AUTOMOUNT</a> features
for virtual (non-SCSI) tape devices.
<p>
<dl> <!-- begin Emulated tape types of emulation -->
<a name="AWS"></a>
<dt><b>AWSTAPE virtual tape files</b>
<dd><p>
These contain a complete tape in one file. AWSTAPE files
consist of variable length EBCDIC blocks. Each block is
preceded by a 6-byte header. Filemarks are represented by
a 6-byte header with no data. This is the same format as is
used by the P/390.
The argument specifies the location of the AWSTAPE file
(for example <code>ickdsf.aws</code>)
<p>
<a name="FAKETAPE"></a>
<dt><b>FakeTape virtual tape files</b>
<dd><p>
These contain a complete tape in one file. FakeTape files
consist of variable length EBCDIC blocks. Each block is
preceded by a 12-ASCII-hex-character header. Filemarks are represented by
a 12-character header with no data. The FakeTape format is
used by the Flex-ES system from Fundamental Software Inc (FSI).
The argument specifies the location of the FakeTape file
(for example <code>ickdsf.fkt</code>). Note: "FLEX-ES" and
"FakeTape" are trademarks of Fundamental Software, Inc.
<p>
<a name="HET"></a>
<dt><b>HET virtual tape files</b> &nbsp;&nbsp; (<b>H</b>ercules <b>E</b>mulated <b>T</b>ape)
<dd><p>
These contain a complete tape in one file and have the same
structure as the AWSTAPE format with the added ability to have
compressed data.
The first argument specifies the location of the HET file. The
filename must end with ".het" to be recognized by Hercules as an
HET file.
(for example <code>023178.het</code>)
<p>
Additional arguments that allow you to control various HET settings
are:
<p>
<dl> <!-- begin Additional HET arguments -->
<dt><code>AWSTAPE</code>
<dd><p>
The <code>AWSTAPE</code> argument causes HET files to
be written in AWSTAPE format. This basically, disables
the additional features provided by the HET format.
<p>
<dt><code>COMPRESS=<em>n</em></code>
<dt><code>IDRC=<em>n</em></code>
<dd><p>
<code>COMPRESS</code> and <code>IDRC</code> control
whether compression should be used when writing to HET
files. The value <code><em>n</em></code> &nbsp;can be <code>1</code>
to turn on compression (the default) or <code>0</code> to turn
it off. <code>IDRC</code> is currently a synonym for
<code>COMPRESS</code>, but may be used in the future to
control other emulated tape drive features.
<p>
<dt><code>METHOD=<em>n</em></code>
<dd><p>
The <code>METHOD</code> option allows you to specify
which compression method to use. You may specify
<code>1</code> for ZLIB compression or <code>2</code>
for BZIP2 compression. The default is <code>1</code>.
<p>
<dt><code>LEVEL=<em>n</em></code>
<dd><p>
The <code>LEVEL</code> option controls the level of
compression. It ranges from <code>1</code> for fastest
compression to <code>9</code> &nbsp;for best compression.
The default is <code>4</code>.
<p>
<dt><code>CHUNKSIZE=<em>nnnnn</em></code>
<dd><p>
The <code>CHUNKSIZE</code> option allows you to create
HET files that contain different chunk sizes. The AWSTAPE
(and therefore the HET) format allows each tape block to be
logically broken up into smaller chunks. For instance, if
your S/3x0 application creates tapes with a block size of
27998, those blocks would be broken down into
<code><em>nnnnn</em></code> &nbsp;sized chunks.
The range is from <code>4096</code>
to <code>65535</code>, the latter being the default.
Decreasing the value from its default may reduce compression
performance.
For compatability with AWSTAPE files created by the P/390,
specify <code>AWSTAPE</code> with <code>CHUNKSIZE=4096</code>.
<p>
</dl> <!-- end Additional HET arguments -->
<p>
<dt>The following additional parameters apply to
<b><a href="#AWS">AWS</a></b>, <b><a href="#HET">HET</a></b>
and <b><a href="#FAKETAPE">FakeTape</a></b> virtual tape files:
<dd><p>
<dl> <!-- begin Additional AWS/HET/FAKE parameters -->
<dt><code>MAXSIZE</code>=<i>n[s]</i> &nbsp;&#124;&nbsp; <code>MAXSIZEK</code>=<i>n</i>
&nbsp;&#124;&nbsp; <code>MAXSIZEM</code>=<i>n</i>
<dd><p>
Specifies the maximum size (in bytes, Kilobytes or Megabytes)
that the emulated file is allowed to grow to.
<p>
Or, nnns where s is either K - KILO, M - MEGA, G - GIGA, or T - TERA - BYTES
<p>
Specifying zero for this parameter means "unlimited" (i.e. there is no limit).
Note: "T" is not available on all platforms.
<p>
<dt><code>EOTMARGIN</code>=<em>n[s]</em>
<dd><p>
Specifies the number of bytes remaining before reaching <em>maxsize</em>
at which point the tape device will signal the presence of the "End of Tape"
marker (reflector), thus allowing the program to switch to the next tape.
<p>
Value is either n = bytes, or ns where s is either a K, M, G, or T multiplier.
<p>
<dt><code>READONLY</code>=<em>n</em>
<dd><p>
Specifies whether the tape is mounted read-only (without a write
ring or with the cartridge protect switch set to "write
protect"). A parameter of 1 means read-only; a parameter of 0
means read-write. If READONLY=1, RO or NORING is not specified,
the default is READONLY=0. Note that READONLY=0 does not override
the host system file permission settings for the underlying AWS or
HET file. If the AWS or HET file is marked read-only, the tape
will be mounted read-only despite specification of READONLY=0.
<p>
<dt><code>RO</code>
<dt><code>NORING</code>
<dd><p>
Specifies that the tape is mounted read-only (without a write
ring or with the cartridge protect switch set to "write
protect"). RO and NORING are equivalent to READONLY=1.
<p>
<dt><code>RW</code>
<dt><code>RING</code>
<dd><p>
Specifies that the tape should be mounted read-write, if possible.
RW and RING are equivalent to READONLY=0. This is the default if
RO, NORING or READONLY=1 is not specified. Note that RW and RING
do not override the host system file permission settings for the
underlying AWS or HET file. If the AWS or HET file is marked
read-only, the tape will be mounted read-only despite specification
of RW or RING.
<p>
<dt><code>DEONIRQ</code>=<em>n</em>
<dd><p>
Specifies whether a device end is presented if intervention is
required during tape motion. A parameter of 1 selects this
option; a parameter of 0 turns it off.
<p>
<a name="noautomount"></a>
<dt><code>NOAUTOMOUNT</code>
<dd><p>
Indicates support for guest-initiated automatic tape volume
mounting is to always be disabled for this tape device.
<p>
Automatic guest tape-mount support is automatically globally
enabled for all virtual (non-SCSI) tape devices by default
whenever an allowable automount directory is defined via the
<a href="#AUTOMOUNT">AUTOMOUNT</a> configuration file statement
or the <code>automount</code> panel command.
The <code>NOAUTOMOUNT</code> option allows you to specifically
disable such support for a given device.
<p>
The automount feature enables software running in guest operating
systems to automatically mount, unmount and/or query for themselves
the host "virtual tape volume" filename mounted on a tape drive,
via the use of special CCW opcodes (0x4B Set Diagnose and 0xE4
Sense Id) without any intervention on the part of the Hercules
operator. An example of such a program for DOS/VSE called
<code>TMOUNT</code> is provided in the <code>util</code>
subdirectory of the distributed source code.
<p>
This is a sticky option. When specified, automount support for
the device remains disabled until the option is specifically
removed via a <code>devinit</code> command <em>without</em> the option
specified. This means if <code>NOAUTOMOUNT</code> is enabled
for a device while global automount functionality is currently
disabled (because no <a href="#AUTOMOUNT">AUTOMOUNT</a> statement
was specified at Hercules startup), then automount functionality
remains disabled for the device even should global automount
functionality be later manually enabled via an
<code>automount</code> panel command.
<p>
When the 0x4B Set Diagnose CCW is used to auto-mount a virtual
tape volume onto a given tape drive, an absolute (fully-qualified)
pathname should normally always be specified, but need not be
if a path relative to the currently defined "default allowable"
automount directory is used instead.
<p>
The default allowable
automount directory is always the first "allowable" directory
that was defined, or else the current directory if no allowable
directories were specifically defined. (There is always a default
allowable directory whenever any allowable or unallowable automount
directories are defined.)
<p>
Fully-resolved, absolute-full-path filenames are defined as being
those which, for Windows, have a ':' (colon) in the second
position or, for other host operating systems (e.g. Linux), have
a '/' (slash) in the first position. Paths which start with a '.'
(period) are considered relative paths and will always be appended
to the currently defined default allowable automount directory,
before being resolved into fully-qualified paths by the host system.
(I.e. only fully-resolved absolute pathnames are used in the
performance of the actual automatic tape volume mount.)
<p>
For example, if more than one allowable automount directory is
defined and the volume wishing to be mounted happens to reside in
the second one, then a fully-qualified absolute pathname should
of course be specified (or else one that is relative to the
default directory which happens to resolve to the desired file).
<p>
All attempts to automount host files in a "disallowed"
directory or any of its subdirectories will be rejected.
Similarly any attempt to automount a file which is not
within any "allowable" directory or subdirectory will
be rejected. An error message is always issued in such cases.
A message is also issued whenever a successful mount or unmount
is performed.
<p>
A sample guest automount program called <code>TMOUNT</code> for
the DOS/VSE operating system is provided in the
<code>util</code> subdirectory of the distributed source code.
</dl> <!-- end Additional AWS/HET/FAKE parameters -->
<p>
<a name="OMA"></a>
<dt><b>Optical Media Attach (OMA) virtual tape files</b>
<dd><p>
These are read-only files which usually reside on CDROM.
OMA virtual tapes consist of one CDROM file corresponding
to each physical file of the emulated tape. An ASCII text
file called the tape descriptor file (TDF) specifies the
names of the files which make up the virtual tape.
The argument specifies the name of the tape descriptor
file (for example <code>/cdrom/tapes/uaa196.tdf</code>)
<p>
Each file on the virtual tape can be in one of three formats:
<p>
<dl>
<dt><code>TEXT</code>
<dd><p>
<b><i>TEXT</i></b> files consist of variable length
ASCII records delimited by carriage return line feed
sequences at the end of each record. Each record is
translated to EBCDIC and presented to the program as
one physical tape block.
<p>
<dt><code>FIXED <em>nnnnn</em></code>
<dd><p>
<b><i>FIXED</i></b> files consist of fixed length
EBCDIC blocks of the specified length
(<code><em>nnnnn</em></code>)
<p>
<dt><code>HEADERS</code>
<dd><p>
<b><i>HEADERS</i></b> files consist of variable
length EBCDIC blocks. Each block is preceded by a
12-byte header.
<p>
</dl>
<p>
If you have any IBM manuals in Bookmanager format on CDROM,
you can see some examples of TDF files in the
<code>\TAPES</code> directory on the CDROM.
<p>
<a name="SCSI"></a>
<dt><b>Real SCSI attached tape drives</b>
<dd><p>
These are real tape drives attached to the host machine via a SCSI
interface. Hercules emulation always makes the drive appear as a
channel attached device such as 3420 or 3480, although the underlying
physical drive may be any type of SCSI attached tape drive, including
4mm or 8mm DAT, DLT, SCSI attached 3480/3490 cartridge drives, and
SCSI attached 3420 open reel tape drives.
<p>
Host-attached SCSI tapes are read and written using variable length
EBCDIC blocks and filemarks exactly like a mainframe tape volume, and
as a result can be freely used/exchanged on either (i.e. SCSI tapes
created on a real mainframe can subsequently be read by Hercules just
fine, and a SCSI tape created by Hercules can be subsequently read on
a mainframe just fine, thus providing a convenient means of exchanging
data between the two).
<p>
If you plan on using SCSI tapes with Hercules you might also be interested
in the <a href="#SCSIMOUNT">SCSIMOUNT</a> configuration option.
<p>
The only <i>required</i> device statement parameter for SCSI attached tape
drives is the name of the device as it is known
by the host operating system,
usually &nbsp;"<code><b>/dev/nst0</b></code>"&nbsp; <i>(for Linux or
Windows)</i> or &nbsp;"<code><b>\\.\Tape0</b></code>" &nbsp; <i>(for
Windows only)</i>, where '0' means tape drive number
0 (your first or only host-attached SCSI tape drive), '1' means your
second host-attached SCSI tape drive, etc.
<p>
Depending on what actual model of SCSI tape drive you
actually have and how it behaves, you may need to specify one or more
additional optional parameters for Hercules to provide proper emulation
of the desired device type.
For example: a <b>Quantum 'DLT' (Digital Linear Tape) SCSI</b> tape drive does
not return nor use a block-id format compatible with 3480/3490 drives
(it instead uses a full 32-bit block-id just like the model 3590 does).
It also does not support the Erase Gap CCW at all.
<p>
Thus, in order to use, for example, a Quantum DLT drive with Hercules,
you <i>MUST</i> specify some special additional options to prevent the
Erase Gap command from being issued to the drive as well as to inform
Hercules that the drive uses 32-bit block-ids.
<p>
<b>Please note</b> that the below options define how the actual SCSI hardware
device behaves, which is completely different from the way the <i>emulated</i>
device will appear to behave to your guest. That is to say, if you define
your tape drive to Hercules as a 3480 device, then Hercules will perform
3480 device type emulation such that the device appears to your guest o/s
as if it were a 3480 device. If the <i>actual</i> SCSI device behaves as
a 3590 device however (perhaps using/returning 32-bit block-ids instead
of the expected 22-bit format block-ids that 3480's use), then you <i>MUST</i>
specify the <code>--blkid-32</code> special option on your Hercules device
statement so that Hercules's emulation logic can know that it needs to
translate 22-bit block-ids to 32-bit ones before sending them to the
actual SCSI hardware (and vice versa: to translate 32-bit block-ids from
the actual SCSI drive into 22-bit format block-ids that your guest expects
from a 3480 device).
<p>
<a name="Quantum"></a>
<center><h4>Special options for SCSI tapes</h4></center>
<p>
As explained just above, certain model SCSI tape drives such as the Quantum
DLT series may require special handling in order to provide the desired proper
device type emulation. These special options are:
<p>
<dl>
<dt><code>--no-erg</code>
<dd><p>
This option is intended to prevent issuance of the Erase Gap
command to those SCSI tape drives which do not support it (such
as the Quantum DLT series). It causes Hercules's device emulation
logic to ignore any Erase Gap commands issued to the drive and
to return immediate 'success' instead.
<p>
This option should
only be used (specified) for drives such as the Quantum, which
support switching from read mode to write mode in the middle of
a data stream without the need of an intervening Erase Gap command.
Specifying it for any other model SCSI drive may cause incorrect
functioning as a result of the Erase Gap command not being issued
to the actual SCSI hardware.
<p>
Check the manufacturer information for your particular model of
SCSI attached tape drive (and/or use Fish's
"<a href="http://www.softdevlabs.com/free">ftape</a>"
Windows utility)
to determine whether or not this option is needed for your
particular drive.
<p>
<dt><code>--blkid-32</code>
<dd><p>
This option indicates that your SCSI attached tape drive only
supports 32-bit block-ids (as used by 3590 drives) and not the 22-bit
format used by 3480/3490 drives. You should only specify this option
if you intend to define the drive as a model 3480 or 3490 device, and
then only if your actual SCSI drive uses 32-bit block-ids of course.
If you define your Hercules tape drive as a model 3590 device however,
then this option is of course not needed since model 3590 drives
are already presumed to use 32-bit block-ids.
<p>
Specifying this option on a 3480/3490 device statement will cause
Hercules device emulation logic to automatically translate the actual
SCSI tape drive's 32-bit block-id into 22-bit format before returning
it back to the guest operating system (since that is the format it
expects it to be in for a model 3480/3490 drive), and to translate the
guest's 22-bit format block-id into 32-bit format before sending it
to the actual SCSI hardware (since that is the format that the actual
hardware requires it to be in).
<p>
<dt><code>--blkid-22</code>
<dd><p>
The complete opposite of the above <code>--blkid-32</code> option.
</dl>
<p>
</dl> <!-- end Emulated tape types of emulation -->
<hr width="50%"><p>
<a name="ctca"></a>
<a name="3088"></a>
<dt><em>Channel-to-channel adapters</em>
<dd><p>
The first argument defines the emulation type, and the remaining
arguments depend on the chosen emulation type. If the first argument
is not a recognized emulation type, then the driver will operate as
in Hercules Version 1, using Willem Konynenberg's vmnet package, as
described in Axel Schwarzer's
<a href="http://www.kiyoinc.com/herc3088.html">CTCA 3088</a> document.
<p>
The following are the emulation types currently supported:
<p>
<dl> <!-- begin emulation types -->
<a name="CTCI"></a>
<dt><b>CTCI</b> &nbsp; &nbsp; (Channel to Channel link to TCP/IP stack)
<dd><p>
A point-to-point IP connection with the TCP/IP stack of the
driving system on which Hercules is running. See the
<a href="herctcp.html">Hercules TCP/IP</a> page for unix details,
in particular the use of preconfigured interfaces.
<p>
The Windows implementation is different from the unix one. See Fish's
<a href="http://www.softdevlabs.com/ctci-win">CTCI-WIN</a>
page for further details and information.
<p>
For unix systems, such as Linux, BSD, and OSX, you may use
preconfigured interfaces or you may
request Hercules to configure the interface for you.
In the first case you must know and supply the name of the interface to use;
in the second case the kernel supplies an interface name.
<p>
<dl> <!-- begin CTCI parms -->
<dt>Required for Linux when using a preconfigured interface:
<dd><p>
<dl>
<dt><code><em>ifname</em></code>
<dd><p>
specifies the interface name of an
interface that is already configured.
The flag <code>--if</code> may optionally be specified
before the name.
<p>
Specify no IP addresses or other arguments as the
information is already configured into the interface.
<p>
</dl>
<dt>Required for Linux when not using a preconfigured interface,
and for Windows:
<dd><p>
<dl> <!-- begin Required for both Linux and Windows -->
<dt><code><em>guestip</em></code>
<dd><p>
specifies the IP address of the guest operating system
running under Hercules.
<p>
<dt><code><em>hostip</em></code>
<dd><p>
specifies the IP address of the host (Linux or Windows) side
of the point-to-point link. This may or may not be the same
as your system's regular IP address. For Windows, if the
host system is configured with DHCP, this should instead be
the MAC address of the Ethernet adapter you wish to use to
have Hercules communicate with the outside world.
<p>
</dl> <!-- end Required for both Linux and Windows -->
<p>
<dt>Optional for Windows:
<dd><p>
If these arguments are specified, they must precede the required
arguments.
<p>
<dl> <!-- begin Optional for Windows -->
<dt><code>-m <em>MAC address</em></code> &nbsp;&nbsp; or &nbsp; <code>--mac <em>MAC address</em></code>
<dd><p>
where <em>'MAC address'</em> is the optional hardware address for
the virtual interface in the format: hh:hh:hh:hh:hh:hh. The default value
is '00:00:5E:nn:nn:nn' where the <i>:nn:nn:nn</i> portion is constructed
from the last 3 octets of the specified <code><i>guestip</i></code>.
<p>
<dt><code>-k &nbsp;<em>kernel-capture-buffer-size</em></code>
<dd>
<dt><code>-i &nbsp;<em>tuntap32-i/o-buffer-size</em></code>
<dd><p>
See Fish's
<a href="http://www.softdevlabs.com/ctci-win">CTCI-WIN</a>
page for further details and information.
<p>
</dl> <!-- end Optional for Windows -->
<p>
<dt>Optional for both Linux and Windows:
<dd><p>
If these arguments are specified, they must precede the required
arguments:
<p>
<dl> <!-- begin Optional for both Linux and Windows -->
<dt><code>-n <em>name</em></code> &nbsp;&nbsp; or &nbsp; <code>--dev <em>name</em></code>
<dd><p>
specifies the name of the tunnel device to use.
<p>
The default
for Linux is <code>/dev/net/tun</code>
(which is correct for version 2.4
and above of the Linux kernel).
The default for OSX is <code>/dev/tun0</code>.
<p>
For Windows, specify the IP address or MAC address of the
real Windows adapter to emulate the virtual guest's adapter on.
The default is the first adapter found according to Windows'
adapter binding order, which may not be the one you want if
you have multiple adapters.
<p>
Refer to the Help file included with Fish's
<a href="http://www.softdevlabs.com/ctci-win">CTCI-WIN</a> product
for for more information about adapter binding order and
for general information regarding CTCI-WIN configuration.
<p>
<dt><code>-s <em>netmask</em></code>
<dd><p>
where <em>netmask</em> is the netmask to use for the
automatically added point-to-point route in standard
dotted internet noitation (e.g. 255.255.255.0)
<p>
<dt><code>-x <em>name</em></code> &nbsp;&nbsp; or &nbsp; <code>--if <em>name</em></code>
<dd><p>
specifies the name of the network interface to use.
<p>
There is no default for this argument as the kernel
assigns an interface name if none is provided.
<p>
<dt><code>-d</code> &nbsp;&nbsp; or &nbsp; <code>--debug</code>
<dd><p>
specifies that debugging output is to be produced on the
Hercules control panel. This should normally be left
unspecified.
<p>
</dl> <!-- end Optional for both Linux and Windows -->
</dl> <!-- end CTCI parms -->
<p><br>
<a name="CTCT"></a>
<dt><b>CTCT</b> &nbsp; &nbsp; (Channel to Channel Emulation via TCP connection)
<dd><p>
An emulated CTCA to another Hercules system.
This emulation mode appears to the operating system running in
the Hercules machine as an IBM 3088 Channel to Channel Adapter.
It provides communication via a TCP connection with another
instance of the CTCT driver, and is designed to carry TCP/IP
communications between two guest TCP/IP stacks.
CTCT may also be used for communication between the client and
server components of the
<a href="http://home.comcast.net/~mvsddt/">MVS Dynamic Debug Tool</a>.
<p>
Four arguments are required:
<p>
<dl> <!-- begin CTCT parms -->
<dt><code><em>lport</em></code>
<dd><p>
specifies the local TCP port. This is the TCP port that
Hercules will listen on for this CTCA.
<p>
<dt><code><em>rhost</em></code>
<dd><p>
specifies the remote host. This is the name or IP address
of the remote system that Hercules is running on, not the
name or IP address of the OS running on that copy of
Hercules.
<p>
<dt><code><em>rport</em></code>
<dd><p>
specifies the remote TCP port. The rport parameter on this
system must match the lport parameter on the remote system,
and vice versa.
<p>
<dt><code><em>bufsize</em></code>
<dd><p>
specifies the buffer size for the link. If this link is used
for IP traffic, this parameter should be more than the MTU
of the interface definition in the OS.
<p>
</dl> <!-- end CTCT parms -->
<p>
Note: CTCT only supports IP traffic. Use <a href="#CTCE">CTCE</a>
to transport general purpose payloads such as NJE, SNA, PVM, etc.
<p>
<p><br>
<a name="CTCE"></a>
<dt><b>CTCE</b> &nbsp; &nbsp; (Enhanced Channel to Channel Emulation via TCP connection)
<dd><p>
The CTCE device type will emulate a real 3088 Channel to
Channnel Adapter also for non-IP traffic, enhancing the CTCT
capabilities. CTCE connections are also based on TCP/IP between
two (or more) Hercules instances, and requires an even-odd pair
of port numbers per device side. Only the even port numbers are
to be configured; the odd numbers are just derived by adding 1
to the (configured) even port numbers. The socket connection
pairs cross-connect, the arrows showing the send->receive
direction :
<pre>
x-lport-even -> y-rport-odd
x-lport-odd <- y-rport-even
</pre>
<p>
Three arguments are required:
<p>
<dl> <!-- begin CTCE parms -->
<dt><code><em>lport</em></code>
<dd>is the even TCP/IP port on the local system.
<dt><code><em>raddress</em></code>
<dd>is the IP address of the remote system.
<dt><code><em>rport</em></code>
<dd>is the even TCP/IP port on the remote system.
</dl>
<p>
The remaining arguments are optional:
<p>
<dl>
<dt><code><em>mtu</em></code>
<dd>optional mtu buffer size, defaults to 32778
<dt><code><em>sml</em></code>
<dd>optional small minimum for mtu, defaults to 8
</dl> <!-- end CTCE parms -->
<p>
A sample CTCE device configuration is shown below:
<p>
Hercules PC Host A with IP address 192.168.1.100 :
<pre>
0E40 CTCE 30880 192.168.1.200 30880
0E41 CTCE 30882 192.168.1.200 30882 </pre>
<p>
Hercules PC Host B with IP address 192.168.1.200 :
<pre>
0E40 CTCE 30880 192.168.1.100 30880
0E41 CTCE 30882 192.168.1.100 30882 </pre>
<p>
CTCE connected Hercules instances can be hosted on either Unix
or Windows platforms, both sides do not need to be the same.
<p>
<p><br>
<a name="LCS"></a>
<dt><b>LCS</b> &nbsp; &nbsp; (LAN Channel Station Emulation)
<dd><p>
An emulated Lan Channel Station Adapter.
This emulation mode appears to the operating system running in
the Hercules machine as an IBM 8232 LCS device, an IBM 2216
router, a 3172 running ICP (Interconnect Communications Program),
the LCS3172 driver of a P/390, or an IBM Open Systems Adapter.
<p>
Rather than a point-to-point link, this emulation creates a
virtual ethernet adapter through which the guest operating system
running in the Hercules machine can communicate. As such, this
mode is not limited to TCP/IP traffic, but in fact will handle
any ethernet frame.
<p>
The configuration statement for LCS is as follows:
<p>
NOTE: There are no required parameters for the LCS emulation,
however there are several options that can be specified on the
config statement:
<p>
NOTE: On the MAC OS X Platform, the long option format (--xxx) is not
supported. Only the short option format (-x : one dash, one letter) should
be used.
<p>
<dl> <!-- begin LCS parms -->
<dt><code>-n <em>devname</em></code> &nbsp;&nbsp; or &nbsp; <code>--dev <em>devname</em></code>
<dd><p>
where <em>devname</em> is:
<p>
<dl> <!-- begin 'devname' -->
<dt>(Linux/Unix)
<dd><p>
the name of the TUN/TAP special character device,
normally /dev/net/tun.
<p>
<dt>(Windows)
<dd><p>
is either the IP or MAC address of the driving
systems network card. Note: If this option is omitted,
then TunTap32 automatically selects the first network card
it finds, which may not be desirable for some users.
<p>
</dl> <!-- end 'devname' -->
<p>
<dt><code>-o <em>filename</em></code> &nbsp;&nbsp; or &nbsp; <code>--oat <em>filename</em></code>
<dd><p>
where <em>filename</em> specifies the filename of the
OSA Address Table (OAT). If this option is specified, the optional
<code>--mac</code> and <em>guestip</em> entries are ignored in preference to
statements in the OAT. (See further below for the <a href=#OAT>syntax
of the OAT</a>)
<p>
<dt><code>-m <em>MAC Address</em></code> &nbsp;&nbsp; or &nbsp; <code>--mac <em>MAC address</em></code>
<dd><p>
where <em>MAC Address</em> is the optional hardware address of
the interface in the format: hh:hh:hh:hh:hh:hh. If you use the
<code>--oat</code> option, do not specify an address here.
<p>
<dt><code><em>guestip</em></code>
<dd><p>
is an optional IP address of the Hercules
(guest OS) side. Note: This is only used to
establish a point-to-point routing table entry
on driving system. If you use the <code>--oat</code> option,
do not specify an address here.
<p>
<a name="OAT"></a>
<dt><b>OAT syntax</b>
<dd><p>
The syntax for the OSA Address Table (OAT) is as follows:
<p>
<table border=1 cellpadding=10><tr><td>
<pre><code>
*********************************************************
* Dev Mode Port Entry specific information... *
*********************************************************
0400 IP 00 PRI 172.021.003.032
0402 IP 00 SEC 172.021.003.033
0404 IP 00 NO 172.021.003.038
0406 IP 01 NO 172.021.002.016
040E SNA 00
HWADD 00 02:00:FE:DF:00:42
HWADD 01 02:00:FE:DF:00:43
ROUTE 00 172.021.003.032 255.255.255.224
</code></pre>
</td></tr></table>
<p>
<dl> <!-- begin LCS OAT parms -->
<dt>where:
<dd><p>
<dl> <!-- (begin INDENT) -->
<dt><code><em>Dev</em></code>
<dd>is the base device address
<p>
<dt><code><em>Mode</em></code>
<dd>is the operation mode: IP or SNA.
<p>
<i><b>Note:</b> &nbsp;the SNA operation mode is NOT currently implemented.</i>
<p>
<dt><code><em>Port</em></code>
<dd>is the virtual (relative) adapter number.
<p>
</dl> <!-- (end INDENT) -->
</dl> <!-- end LCS OAT parms -->
<p>
For IP modes, the entry specific information is as follows:
<p>
<dl> <!-- begin IP Mode parms -->
<dl> <!-- (begin INDENT) -->
<dt><code>PRI &#124; SEC &#124; NO</code>
<dd><p>
specifies where a packet with an unknown IP
address is forwarded to. PRI is the primary
default entry, SEC specifies the entry to use
when the primary is not available, and NO
specifies that this is not a default entry.
<p>
<dt><code><em>nnn.nnn.nnn.nnn</code></em>
<dd><p>
specifies the home IP address
</dl> <!-- (end INDENT) -->
</dl> <!-- end IP Mode parms -->
<p>
When the operation mode is IP, specify only the even (read)
device number <em>dev</em>. The odd (write) address will be
create automatically.
<p>
<i><b>Note:</b> &nbsp;the SNA operation mode is NOT currently implemented.</i>
<p>
Additionally, a HWADD and/or ROUTE statement
may also be included in the OAT:
<p>
<dl> <!-- begin HWADD and ROUTE -->
<dl> <!-- (begin INDENT) -->
<dt><code>HWADD &nbsp;pp <i>&nbsp;hh:hh:hh:hh:hh:hh</i></code>
<dd><p>
Use the HWADD to specify a hardware (MAC) address for a
virtual adapter. The first parameter after HWADD specifies
the relative adapter for which the address is applied.
<p>
<dt><code>ROUTE &nbsp;pp <i>&nbsp;nnn.nnn.nnn.nnn &nbsp;...</i></code>
<dd><p>
The ROUTE statement is included for convenience. This allows the
hercifc program to create a network route for this specified
virtual adapter. Please note that it is not necessary to include
point-to-point routes for each IP address in the table since this
is done automatically by the emulation module.
<p>
</dl> <!-- (end INDENT) -->
</dl> <!-- end HWADD and ROUTE -->
The read/write devices can be swapped by coding the odd address
of the even-odd pair in the OAT
<p>
Up to 4 virtual (relative) adapters 00-03 are currently supported.
</dl> <!-- end LCS parms -->
<p>
If no OAT is specified, the emulation module
will create the following:
<p>
<ul>
<li>An ethernet adapter (port 0) for TCP/IP traffic only.
<li>Two device addresses will be defined (devnum and devnum + 1).
</ul>
<p>
<p><br>
<a name="PTP"></a>
<dt><b>PTP</b> &nbsp; &nbsp; (MPCPTP/MPCPTP6 Channel to Channel link)
<dd><p>
A point-to-point IP connection with the TCP/IP stack of the
host system on which Hercules is running.
From the point of view of the guest image running in the Hercules
machine it appears to be an MPCPTP and/or MPCPTP6 ESCON CTC link to
another image.
<p>
For *nix systems, such as Linux, BSD, and OSX, you may use
preconfigured interfaces or you may request Hercules to configure
the interface for you.
In the first case you must know and supply the name of the interface
to use; in the second case the kernel supplies an interface name.
See the <a href="herctcp.html">Hercules TCP/IP</a> page for more details.
<p>
<dl> <!-- begin PTP parms -->
<dt>Required for *nix when using a preconfigured interface:
<dd><p>
<dl> <!-- begin Required for *nix preconfigured -->
<dt>[<code>-x</code>/<code>--if</code>] <code><em>ifname</em></code>
<dd><p>
specifies the interface name of a TUN interface that is
already configured.
<p>
Specify no host names or IP addresses or other arguments as
the information is already configured into the interface.
<p>
</dl> <!-- end Required for *nix preconfigured -->
<dt>Required for *nix when not using a preconfigured interface,
and for Windows:
<dd><p>
<dl> <!-- begin Required for both *nix not preconfigured and Windows -->
<dt><code><em>guest1</em></code>
<dd><p>
specifies the host name or IP address of the guest
operating system running under Hercules.
<p>
<dt><code><em>host1</em></code>
<dd><p>
specifies the host name or IP address of the host
(Linux or Windows) side of the point-to-point link.
<p>
<dt><code><em>guest2</em></code>
<dd><p>
specifies the host name or IP address of the guest
operating system running under Hercules.
<p>
<dt><code><em>host2</em></code>
<dd><p>
specifies the host name or IP address of the host
(Linux or Windows) side of the point-to-point link.
<p>
<dt><code><em>guest1</em></code> and <code><em>host1</em></code>
must both be of the same address family, i.e. both IPv4 or
both IPv6.
<p>
<dt><code><em>guest2</em></code> and <code><em>host2</em></code>,
if specified, must both be of the same address family, i.e. both
IPv4 or both IPv6, and must not be of the same address family as
<code><em>guest1</em></code> and <code><em>host1</em></code>.
<p>
<dt>If a host name is specified for <code><em>guest1</em></code>,
and the host name can be resolved to both an IPv4 and an IPv6
address, use either the <code>-4</code>/<code>--inet</code>
or the <code>-6</code>/<code>--inet6</code> option to
specify which address family should be used;
if neither the <code>-4</code>/<code>--inet</code> nor the
<code>-6</code>/<code>--inet6</code> option is specified,
whichever address family the resolver returns first will
be used.
<p>
<dt><code><em>host1</em></code> or <code><em>host2</em></code> can
be followed by the prefix size expressed in CIDR notation,
e.g. 192.168.1.1/24 or 2001:db8:3003:1::543:210f/48.
For IPv4 the prefix size can have a value from 0 to 32;
if not specified a value of 32 is assumed.
For IPv6 the prefix size can have a value from 0 to 128;
if not specified a value of 128 is assumed.
For IPv4 the prefix size is used to produce the equivalent
subnet mask; for example, a value of 24 produces a subnet
mask of 255.255.255.0.
<p>
<dt>If <code><em>guest1</em></code>, <code><em>host1</em></code>,
<code><em>guest2</em></code> or <code><em>host2</em></code>
are numeric IPv6 addresses, they can be between braces,
e.g. [2001:db8:3003:1::543:210f].
<p>
</dl> <!-- end Required for both *nix not preconfigured and Windows -->
<p>
<dt>Optional for *nix:
<dd><p>
If these arguments are specified, they must precede the required
arguments.
<p>
<dl> <!-- begin Optional for *nix -->
<dt><code>-t <em>size</em></code> &nbsp;&nbsp; or &nbsp; <code>--mtu <em>size</em></code>
<dd><p>
where <code><em>size</em></code> is the maximum transmission
unit size. The default size is 1500.
<p>
<dt><code>-x <em>name</em></code> &nbsp;&nbsp; or &nbsp; <code>--if <em>name</em></code>
<dd><p>
specifies the name of the TUN interface to use.
There is no default for <code><em>name</em></code>.
<p>
</dl> <!-- end Optional for *nix -->
<p>
<dt>Optional for Windows:
<dd><p>
If these arguments are specified, they must precede the required
arguments.
<p>
<dl> <!-- begin Optional for Windows -->
<dt><code>-m <em>MAC address</em></code> &nbsp;&nbsp; or &nbsp; <code>--mac <em>MAC address</em></code>
<dd><p>
where <em>'MAC address'</em> is the optional hardware address for
the virtual interface in the format: hh:hh:hh:hh:hh:hh. The default value
is '00:00:5E:nn:nn:nn' where the <i>:nn:nn:nn</i> portion is constructed
from the last 3 octets of the specified <code><i>guestip</i></code>.
<p>
<dt><code>-k &nbsp;<em>kernel-capture-buffer-size</em></code>
<dd>
<dt><code>-i &nbsp;<em>tuntap32-i/o-buffer-size</em></code>
<dd><p>
Refer to the Help file included with Fish's
<a href="http://www.softdevlabs.com/ctci-win">CTCI-WIN</a> product
for further details and information.
<p>
</dl> <!-- end Optional for Windows -->
<p>
<dt>Optional for both *nix and Windows:
<dd><p>
If these arguments are specified, they must precede the required
arguments:
<p>
<dl> <!-- begin Optional for both *nix and Windows -->
<dt><code>-n <em>name</em></code> &nbsp;&nbsp; or &nbsp; <code>--dev <em>name</em></code>
<dd><p>
specifies the name of the tunnel device to use.
<p>
The default
for Linux is <code>/dev/net/tun</code>
(which is correct for version 2.4
and above of the Linux kernel).
The default for OSX is <code>/dev/tun0</code>.
<p>
For Windows, specify the IP address or MAC address of the
real Windows adapter to emulate the virtual guest's adapter on.
The default is the first adapter found according to Windows'
adapter binding order, which may not be the one you want if
you have multiple adapters.
<p>
Refer to the Help file included with Fish's
<a href="http://www.softdevlabs.com/ctci-win">CTCI-WIN</a> product
for for more information about adapter binding order and
for general information regarding CTCI-WIN configuration.
<p>
<dt><code>-4</code> &nbsp;&nbsp; or &nbsp; <code>--inet</code>
<dd><p>
indicates that when a host name is specified for
<code><em>guest1</em></code>, the host name must
resolve to an IPv4 address.
<dt><code>-6</code> &nbsp;&nbsp; or &nbsp; <code>--inet6</code>
<dd><p>
indicates that when a host name is specified for
<code><em>guest1</em></code>, the host name must
resolve to an IPv6 address.
<dt><code>-d</code> &nbsp;&nbsp; or &nbsp; <code>--debug</code>
<dd><p>
specifies that debugging output is to be produced on the
Hercules control panel. This should normally be left
unspecified.
<p>
</dl> <!-- end Optional for both *nix and Windows -->
</dl> <!-- end PTP parms -->
<p><br>
<a name="QETH"></a>
<dt><b>QETH</b> &nbsp; &nbsp; (OSA/QDIO Ethernet Adapter)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
<i>(<b>Note:</b> This is an experimental driver which may not be fully functional yet.)</i>
<dd><p>
emulates an OSA Express card running in QDIO mode.
Both layer-2 and layer-3 are currently supported.
<dl> <!-- begin QETH parms -->
<dt>Optional for *nix:
<dd><p>
<dl> <!-- begin Optional for *nix -->
<dt><code>ifname &nbsp;<em>interface</em></code>
<dd><p>
specifies the interface name of a host interface
that is already configured (e.g. <code>tun</code>,
<code>tun0</code>, etc). &nbsp;(*nix only)
<p>
</dl> <!-- end Optional for *nix -->
<p>
<dt>Optional for both *nix and Windows:
<dd><p>
<dl> <!-- begin Optional for both *nix and Windows -->
<dt><code>iface &nbsp;<em>device</em></code>
<dd><p>
specifies the name of the host tunnel device to use.
<p>
The default for Linux is
<code>/dev/net/tun</code>
(which is correct for version 2.4 and above of the Linux kernel).
The default for OSX is
<code>/dev/tun0</code>.
For Windows, specify the IP address or MAC address
of your Windows host's real network adapter that the Hercules
driver should use to emulate your virtual guest's adapter on.
The default is the first adapter found according to Windows'
adapter binding order, which may not be the one you want
if you have multiple adapters.
<p>
<dt><code>ipaddr &nbsp;<em>address</em></code>
<dt><code>ipaddr &nbsp;<em>address/prefix</em></code>
<dd><p>
specifies the IPv4 address to be assigned to your virtual OSA Express card.
The address can be optionally followed by a prefix size
expressed in CIDR notation, e.g. <code>192.168.1.1/24</code>.
For IPv4 the prefix size can have a value from 0 to 32.
If not specified a value of 32 is assumed.
The prefix size is used to produce an equivalent subnet mask.
For example, a value of 24 produces a subnet mask of 255.255.255.0.
<p>
<dt><code>netmask &nbsp;<em>mask</em></code>
<dd><p>
specifies the subnet mask to be used with your OSA card.
The <code>netmask</code> option may only be specified when
the subnet mask is not already defined via the optional
prefix size parameter of the <code>ipaddr</code> option.
<p>
<dt><code>ipaddr6 &nbsp;<em>address</em></code>
<dt><code>ipaddr6 &nbsp;<em>address/prefix</em></code>
<dd><p>
specifies the IPv6 address to be assigned to your OSA card.
The address can be optionally followed by the prefix size
expressed in CIDR notation, e.g.
<code>2001:db8:3003:1::543:210f/48</code>.
For IPv6 the prefix size can have a value from 0 to 128. If
not specified a value of 128 is assumed. The prefix size
is used to produce an equivalent subnet mask.
<p>
<dt><code>hwaddr &nbsp;<em>MAC</em></code>
<dd><p>
specifies the MAC address to be assigned to your OSA card.
If not specified then one will be internally generated
in the range 02:00:5E:80:00:00 - 02:00:5E:FF:FF:FF using
the low order 23 bits of the IPv4 address. For example,
if the ipv4 address is 10.1.2.3 the generated MAC address
will be 02:00:5E:81:02:03.
<p>
<dt><code>mtu &nbsp;<em>bytes</em></code>
<dd><p>
specifies the Maximum Transmission Unit to be used.
The maximum transmission unit (MTU) is the largest
packet size, measured in bytes, that can be transmitted
over a network.
<p>
<dt><code>chpid &nbsp;<em>id</em></code>
<dd><p>
specified the channel path identifier to be used
with the device. This is mostly a cosmetic value
but certain guest operating systems such as z/OS
might require it to operate correctly.
<p>
<dt><code>debug</code>
<dd><p>
enables debug logging for the device. When logging is
enabled the Hercules driver logs extra progress and
status messages used to help debug an incorrectly
functioning driver.
<p>
</dl> <!-- end Optional for both *nix and Windows -->
</dl> <!-- end QETH parms -->
</dl> <!-- end emulation types -->
<p><br>
<hr width="50%"><p>
<a name="3380"></a>
<a name="ckddasd"></a>
<dt><em>CKD DASD devices</em>
<dd><p>
The argument specifies the name of a file containing the disk CKD
DASD image or the INET address of a <a href="shared.html">Hercules shared device server</a>.
<p>
The file consists of a 512-byte device header record
followed by fixed length track images. The length of each track
image depends on the emulated device type, and is always rounded
up to the next multiple of 512 bytes.
<p>
Volumes larger than 2GB (for example, the 3390 model 3)
can be supported by spreading the data across more than one file.
Each file contains a whole number of cylinders. The first file
(which contains cylinders 0-2518 in the case of a 3390) usually
has _1 as the last two characters of its name. The ckddasd driver
allocates the remaining files by replacing the last character of
the file name by the characters 2, 3, etc.
<p>
<em><b>Note:</b> &nbsp;When CKD DASD images are spread across multiple files, you must
specify only the first file name (the file with suffix _1) in the
configuration statement.</em>
<p>
If your operating system supports <i>large file sizes</i> (or
<i>64-bit offsets</i>) then volumes larger than 2G can be kept
in a single file.
<p>
Alternatively, the argument may specify the name of a file containing
a compressed CKD DASD image. The CKD driver will automatically detect
whether the file contains a regular CKD image or a compressed CKD
image.
<p>
Refer to "Creating an empty DASD volume" in the "Creating, formatting,
and loading DASD volumes" section of the
<a href="hercload.html">Creating DASD</a>
web page for information on using the 'dasdinit' command/utility to
create compressed dasd files. Refer to the
<a href="cckddasd.html">Compressed Dasd Emulation</a>
page for details on the actual CCKD emulation itself and additional
information on the <a href="cckddasd.html#cckdcommand">CCKD</a>
initialization/tuning control file statement.
<p>
If you specify an INET address, the format is:
<p>
<dl> <!-- begin INET parms -->
<dt><code><em>ip-name-or-addr</em>:<em>port</em>:<em>devnum</em></code>
<dd><p>
<em>ip-name-or-addr</em> specifies the internet name or address
where the <a href="shared.html">Hercules shared device server</a> is running.
<p>
<em>port</em> specifies the port number the shared device server
is listening on. If omitted, the default is 3990.
<p>
<em>devnum</em> specifies the device number on the shared
device server. If omitted, the default is the current device number.
<p>
</dl> <!-- end INET parms -->
<p>
In addition to the above, some additional optional arguments are also
supported.
<p>
<dl> <!-- begin (CKD) additional DASD arguments -->
<dt><code>sf=<em>shadow-file-name</em></code>
<dd><p>
A shadow file contains all the changes made to the emulated dasd since
it was created, until the next shadow file is created. The moment of the
shadow file's creation can be thought of as a snapshot of the current
emulated dasd at that time, because if the shadow file is later removed,
then the emulated dasd reverts back to the state it was at when the snapshot
was taken.
<p>
Using shadow files, you can keep the base file on a read-only device such
as cdrom, or change the base file attributes to read-only, ensuring that
this file can never be corrupted.
<p>
Hercules console commands are provided to add a new shadow file, remove
the current shadow file (with or without backward merge), compress the
current shadow file, and display the shadow file status and statistics
<p>
For detailed information regarding shadow files and their use, please
see the "<a href="cckddasd.html#shadowfiles">Shadow Files</a>" section
of the <a href="cckddasd.html">Compressed Dasd Emulation</a> web page.
<p>
<dt><code>[no]syncio</code>
<dd><p>
syncio enables possible 'synchronous' i/o. This is a dasd i/o feature
wherein guest i/o requests are completed "synchronously" during the
actual emulated execution of the SIO/SSCH (start-i/o / start subchannel)
instruction rather than being deferred and executed asynchronously in
a separate device i/o thread.
<p>
Only i/o which are known to be able to be completed without actually
needing to perform any actual host i/o are completed synchronously (e.g.
whenever the data being requested is found to already be in cache). If
the requested data is not found in the cache, then an actual host i/o
will need to be done and the request is passed to a device i/o thread
to be completed asyncronously instead.
<p>
syncio is the default for ckd. syncio statistics may be displayed via
the Hercules <code>syncio</code> panel command.
<p>
<!-- No longer applicable with current versions of Linux
<b>Note:</b> If you plan on using syncio with <b>Linux/390</b> and/or <b>zLinux</b>
you might also want to take a look at the <a href="#IODELAY">IODELAY</a>
configuration file statement as well.
<p>
-->
<p>
<code>syncio</code> may be abbreviated as
<code>syio</code>
<p>
<dt><code>readonly</code>
<dd><p>
readonly returns "write inhibited" sense when a write is attempted.
Note that not all of the sense bits may be getting set absolutely
correctly however. (Some people have reported getting different
error messages under Hercules than a real machine, but it really
hasn't been an issue for a while now.)
<p>
<code>readonly</code> may be abbreviated as
<code>rdonly</code> or <code>ro</code>
<p>
<dt><code>fakewrite</code>
<dd><p>
fakewrite is a kludge for the readonly sense problem mentioned above.
Here the disk is not intended to be updated (MVS updates the DSCB
last referenced field for a readonly file) and any writes appear to
be successful even though nothing actually gets written.
<p>
<code>fakewrite</code> may be abbreviated as
<code>fakewrt</code> or <code>fw</code>
<p>
<dt><code>[no]lazywrite</code>
<dt><code>[no]fulltrackio</code>
<dd><p>
These options have been deprecated. They are still accepted, but they
do absolutely nothing.
<p>
<code>fulltrackio</code> may be abbreviated as
<code>fulltrkio</code> or <code>ftio</code>
<p>
<dt><code>cu=<em>type</em></code>
<dd><p>
Specifies the type of control unit to which this device is attached.
The use of this parameter does not necessarily imply that
all functions of the specified control unit are emulated,
its only purpose is to force a particular control unit type
to be indicated in the data returned by SENSE ID and similar CCW's.
<p>
The default value depends on the device type:
<blockquote>
<table border=1 cellpadding=3>
<tr align="center"><th>Device type</th><th>Default CU type</dev></th></tr>
<tr align="center"><td>2311</td><td>2841</td></tr>
<tr align="center"><td>2314</td><td>2314</td></tr>
<tr align="center"><td>3330 3340<br>3350 3375<br>3380</td><td>3880</td></tr>
<tr align="center"><td>3390</td><td>3990</td></tr>
<tr align="center"><td>9345</td><td>9343</td></tr>
</table>
</blockquote>
<p>
Other values which may be specified are:
3990-3 and 3990-6.
<p>
Normally the default value is appropriate and this parameter need
not be specified.
<p>
</dl> <!-- end (CKD) additional DASD arguments -->
<p>
<hr width="50%"><p>
<a name="3370"></a>
<a name="fbadasd"></a>
<dt><em>FBA DASD devices</em>
<dd><p>
The argument specifies the name of a file which contains the FBA
DASD image or the INET address of a <a href="shared.html">Hercules shared device server</a>.
<p>
The file consists of fixed length 512-byte records,
each of which represents one physical block of the emulated disk.
<p>
To allow access to a minidisk within a full-pack FBA DASD image
file, two additional arguments may be specified after the file
name:
<p>
<dl> <!-- begin FBA DASD arguments -->
<dt><code><em>origin</em></code>
<dd><p>
specifies the relative block number within the DASD image
file at which the minidisk begins. The number must be less
than the number of blocks in the file. The default origin
is zero.
<p>
<dt><code><em>numblks</em></code>
<dd><p>
specifies the number of 512-byte blocks in the minidisk.
This number must not exceed the number of blocks in the file
minus the origin.
If omitted, or if specified as an asterisk, then the minidisk
continues to the end of the DASD image file.
<p>
</dl> <!-- end FBA DASD arguments -->
<p>
If you specify an INET address the format is:
<p>
<dl> <!-- begin INET parms -->
<dt><code><em>ip-name-or-addr</em>:<em>port</em>:<em>devnum</em></code>
<dd><p>
<em>ip-name-or-addr</em> specifies the internet name or address
where the <a href="shared.html">Hercules shared device server</a> is running.
<p>
<em>port</em> specifies the port number the shared device server
is listening on. If omitted, the default is 3990.
<p>
<em>devnum</em> specifies the device number on the shared
device server. If omitted, the default is the current device number.
</dl> <!-- end INET parms -->
<p>
In addition to the above, some additional optional arguments are also
supported.
<p>
<dl> <!-- begin (FBA) additional DASD arguments -->
<dt><code>sf=<em>shadow-file-name</em></code>
<dd><p>
The handling of shadow files for FBA devices is identical as that for
CKD devices. Please refer to the preceding CKD section for information
regarding use of the <code>sf=</code> shadow file option.
<p>
<dt><code>[no]syncio</code>
<dd><p>
syncio enables possible 'synchronous' i/o and is explained in detail in
the preceding CKD dasd section. Note however that syncio is currently
disabled by default for FBA dasd due to an as yet unresolved problem
and must therefore be specifically enabled if you wish to use it for FBA
dasd.
<p>
<p>
<code>syncio</code> may be abbreviated as
<code>syio</code>
</dl> <!-- end (FBA) additional DASD arguments -->
<p>
<hr width="50%"><p>
<a name="comline"></a>
<dt><em>Communication Line - BSC</em>
<dd><p>
( Preliminary 2703 BSC Support )
<p>
Describes a BSC emulation line entry to either link 2 Hercules engines
or a custom made program emulating a 2780, 3780 or 3x74, or a custom made
program interfacing to a real BSC line.
<p>
The communication is emulated over a TCP connection. All bytes are
transfered as-is (except for doubling DLE in transparent mode) just
like it would over a real BSC link. Emulated EIA (DCD, DTR, CTS,
etc..) or X.21/V.11 leads (C, T, etc..) are treated differently depending
on the DIAL option selected.
<p>
The line emulates a point-to-point BSC link. There is no point-to-multipoint handling.
<p>
The following options define the line emulation behaviour:
<p>
<dl> <!-- begin Communication Adapter parms -->
<dt><code>DIAL=IN &#124; OUT &#124; INOUT &#124; NO</code>
<dd><p>
Specifies call direction (if any). If <code>DIAL=NO</code> is specified, the
TCP outgoing connection is attempted as soon as an 'ENABLE' CCW is executed.
Also, in this mode, an incoming connection will always be accepted. If <code>DIAL=IN&#124;INOUT</code>
is specified, a TCP incoming call is accepted ONLY if an 'ENABLE' CCW is currently
executing on the device. If <code>DIAL=OUT</code>, the 'ENABLE' CCW is rejected.
When <code>DIAL=IN&#124;INOUT</code> is specified, a DIAL CCW allows the application
to establish a TCP connection to a specific host. For other DIAL values,
the DIAL CCW is rejected.
<p>
<dt><code>lhost=<em>hostname</em> &#124; <em>ip address</em> &#124; *</code>
<dd><p>
Specifies which IP address to listen on. This also conditions the network
interface from which incoming calls will be accepted. Specifying '*' means
all incoming TCP calls are accepted, regardless of the destination IP
address or call origin. This is the default value. Specifying a specific
IP address when <code>DIAL=OUT</code> is specified has no effect.
<p>
<dt><code>lport=<em>service name</em> &#124; <em>port number</em></code>
<dd><p>
Specifies the TCP port for which to listen to incoming TCP calls. This
value is mandatory for <code>DIAL=IN&#124;INOUT&#124;NO</code>. It is ignored for <code>DIAL=OUT</code>.
<p>
<dt><code>rhost=<em>hostname</em> &#124; <em>ip address</em></code>
<dt><code>rport=<em>service name</em> &#124; <em>port number</em></code>
<dd><p>
Specifies the remote host and port to which to direct a TCP connection on a
DIAL=NO line when an 'ENABLE' CCW is executed. This option is mandatory when <code>DIAL=NO</code>
is specified. It is ignored for other <code>DIAL</code> values.
<p>
</dl> <!-- end Communication Adapter parms -->
The following options are tuning options. In most cases, using the default values
give the best results
<p>
<dl> <!-- begin Communication Adapter tuning options -->
<dt><code>rto=0 &#124; -1 &#124; <em>nnn</em> &#124; 3000</code>
<dd><p>
Specifies the number of milliseconds before terminating a read on a timeout, when
no read termination control character is received. Specifying 0 means the READ ends
immediately. -1 specifies there is no timeout.
<p>
<dt><code>pto=0 &#124; -1 &#124; <em>nnn</em> &#124; 3000</code>
<dd><p>
Specifies the number of milliseconds before terminating a POLL on a timeout, when
no ACK or NACK sequence is received. Specifying 0 means the POLL ends
immediately. -1 specifies there is no timeout.
<p>
<dt><code>eto=0 &#124; -1 &#124; <em>nnn</em> &#124; 10000</code>
<dd><p>
Specifies the number of milliseconds before terminating an ENABLE operation on a timeout.
the timeout applies when <code>DIAL=NO&#124;IN&#124;INOUT</code> is specified, the outgoing TCP call
fails (<code>DIAL=NO</code>) and there is no previously or currently established TCP connection
for this line. When <code>DIAL=NO</code> is specified, the timeout defaults to 10 seconds.
For <code>DIAL=IN&#124;INOUT</code>, the timeout defaults to -1.
<p>
</dl> <!-- end Communication Adapter tuning options -->
<a name="remtty"></a>
<dt><em>Communication Line - TTY</em>
<dd><p>
( Preliminary 2703 TELE2 TTY Support )
<p>
Describes a 2703 Telegraph Terminal Control Type II (TTY 33/35) stop/start line, providing access to the Host OS via a standard TELNET client.
<p>
To the host OS the line emulates an asynchronous TELE2 connection. The communication is emulated over a TELNET connection.
<p>
The following options define the line emulation behaviour:
<p>
<dl> <!-- begin Communication Adapter parms -->
<dt><code>lport=<em>port number</em></code>
<dd><p>
Specifies the TCPIP port to listen on for incoming TCP calls.
<p>
<dt><code>dial=IN</code>
<dd><p>
Specifies that this line is for in-bound calls. Required.
<p>
<dt><code>tty=1</code>
<dd><p>
Specifies that this definition is for a TTY port. Required
<p>
</dl> <!-- end Communication Adapter parms -->
</dl> <!-- end Arguments for each device type -->
<center><hr width=15% noshade></center>
<p>
If you have a question about Hercules, see the
<a href="hercfaq.html">Hercules Frequently-Asked Questions</a> page.
<p><center><hr width=15% noshade>
<a href="hercinst.html"><img src="images/back.gif" border=0 alt="back"></a>
</center>
<p class="lastupd">Last updated $Date$ $Revision$</p>
</body>
</html>