Deflate (String function) - Revision history

Tom at 13:39, 19 May 2026

2026-05-19T13:39:40Z

← Older revision		Revision as of 13:39, 19 May 2026
Line 3:		Line 3:

	==Syntax==		==Syntax==
	~~{{Template:String~~:Deflate ~~syntax}}~~		<p class="syntax"><span class="term">%outString</span><span class="literal"> =</span> <span class="term">string</span><span class="literal">:Deflate</span><span class="squareb">[</span><span class="literal">(</span> <span class="squareb">[</span><span class="literal" title="Boolean">FixedCode=</span> <span class="term" title="Boolean">boolean</span><span class="squareb">]</span><span class="comma">,</span> <span class="squareb">[</span><span class="literal" title="Boolean">LazyMatch=</span> <span class="term" title="Boolean">boolean</span><span class="squareb">]</span><span class="comma">,</span> -
			<span class="squareb">[</span><span class="literal" title="Number">MaxChain=</span> <span class="term" title="Number">number</span><span class="squareb">]</span><span class="comma">,</span> <span class="squareb">[</span><span class="literal" title="Boolean">Software=</span> <span class="term" title="Boolean">boolean</span><span class="squareb">]</span><span class="literal">)</span><span class="squareb">]</span></p>

	===Syntax terms===		===Syntax terms===
Line 19:		Line 20:
	<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.		<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.
	</ul>		</ul>
	The default value for this argument is <var>False</var> (use dynamic compression).		The default value for this argument is <var>False</var> (use dynamic compression).</td></tr>
	</td></tr>

	<tr><th><var>LazyMatch</var></th>		<tr><th><var>LazyMatch</var></th>
	<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.		<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.
	The default value for this argument is <var>False</var> (do not use "lazy match" compression).		The default value for this argument is <var>False</var> (do not use "lazy match" compression).</td></tr>
	~~<p><b>Note:</b> This parameter has no effect when hardware compression is used (see [[#Hardware vs. software compression\|Hardware vs. software compression]]).</p>~~
	</td></tr>

	<tr><th><var>MaxChain</var></th>		<tr><th><var>MaxChain</var></th>
	<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.		<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.
	The default value for this argument is 0. If specified, it must be between 0 and 99, inclusive.		The default value for this argument is 0. If specified, it must be between 0 and 99, inclusive.</td></tr>
	<p><b>~~Note:~~</b> ~~This~~ parameter ~~has no effect when hardware compression~~ is ~~used (see~~ [[#~~Hardware vs~~. software compression~~\|Hardware vs~~. software compression]]).</p>
			<tr><th><var>Software</var></th>
			<td>[Introduced in Model 204 version 8.0]
			<p><var>Software</var> is an optional, [[Notation conventions for methods#Named parameters\|name required]], parameter that is a <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> value that specifies whether to force the use of software compression instead of hardware compression.</p>
			<ul>
			<li>When <code>software=true</code>, compression is always performed in software, even if the DFLTCC hardware instruction is available on the processor. This can be useful for diagnostic purposes or when byte-for-byte reproducibility with pre-8.0 behavior is required.</li>
			<li>When <code>software=false</code> (the default), hardware compression is used automatically when DFLTCC is available (IBM z15 and above), falling back to software compression on older processors.</li>
			</ul>
			The default value for this argument is <var>False</var>.
	</td></tr>		</td></tr>
	</table>		</table>
Line 45:		Line 51:
	</ul>		</ul>

	==Hardware vs. software compression==		===Hardware vs. software compression===
	~~<p>~~[Introduced in Model 204 version 8.0]~~</p>~~		[Introduced in Model 204 version 8.0]
			<p>On IBM z15 and above processors, the <var>Deflate</var> method automatically exploits the DFLTCC (DEFLate Conversion Call) hardware instruction for significantly improved compression performance. The following differences apply when using hardware compression:</p>
	<p>On IBM z15 and above processors, <var>Deflate</var> automatically ~~uses~~ the DFLTCC (~~Deflate~~ Conversion Call) hardware instruction ~~to perform~~ compression~~. On older processors without DFLTCC support, the existing software implementation is used~~. The ~~choice is made automatically and is transparent to the application.</p>~~

	~~<p>There are some behavioral~~ differences ~~between~~ hardware ~~and software~~ compression ~~that should be noted~~:</p>

	<ul>		<ul>
	<li>The <var>LazyMatch</var> and <var>MaxChain</var> parameters ~~are <b>ignored</b>~~ when hardware compression is used. The ~~DFLTCC~~ hardware uses its own internal ~~compression strategy for match searching, and these parameters have no effect~~. The <var>FixedCode</var> parameter ~~<b>~~is~~</b>~~ honored~~: when~~ <code>fixedCode=true</code>, the hardware ~~uses~~ fixed Huffman codes~~; when <code>fixedCode=false</code> (the default), the hardware generates~~ a Dynamic Huffman Table (~~DHT~~) ~~from the input data for each deflate block~~.~~</li>~~		<li>The <var>LazyMatch</var> and <var>MaxChain</var> parameters have no effect when hardware compression is used. The hardware uses its own internal matching algorithm.
			<li>The <var>FixedCode</var> parameter is honored by both hardware and software compression. When <code>fixedCode=true</code>, the hardware generates compressed data with fixed Huffman codes instead of generating a Dynamic Huffman Table (GDHT).
	<li>~~Hardware compression is <b>non-deterministic</b>: compressing~~ the same input data multiple times may produce different compressed output~~, even with identical parameters. This is because~~ the ~~DFLTCC instruction uses an~~ implementation-dependent hash function for duplicate string matching, as documented in the z/Architecture Principles of Operation. ~~The compressed output~~ is ~~always valid RFC 1951 data and can be decompressed by <var>[[Inflate (String function)\|Inflate]]</var> regardless~~, ~~but applications should~~ not ~~depend on~~ a ~~specific compressed length or byte-for-byte reproducibility of compressed data~~.~~</li>~~		<li>Compressing the same input data multiple times may produce different compressed output due to the implementation-dependent hash function for duplicate string matching, as documented in the z/Architecture Principles of Operation. This is a property of the hardware itself, not a software issue.
			<li>Hardware-compressed data can always be decompressed by any standards-compliant inflate implementation (and vice versa).
	<li>Hardware ~~compression generally provides significantly better throughput than software compression, particularly for larger input~~ data.~~</li>~~
	</ul>		</ul>

	<p>These differences also apply to the <var>[[Gzip (String function)\|Gzip]]</var> and <var>[[Zip (String function)\|Zip]]</var> methods, which use <var>Deflate</var> compression internally.</p>		<p>These differences also apply to the <var>[[Gzip (String function)\|Gzip]]</var> and <var>[[Zip (String function)\|Zip]]</var> methods, which use <var>Deflate</var> compression internally.</p>

Line 65:		Line 65:
	In the following example, <code>%out</code> is set to the compressed version of the given string:		In the following example, <code>%out</code> is set to the compressed version of the given string:
	<p class="code">%out = 'How much wood could a woodchuck chuck':deflate(fixedCode=true)		<p class="code">%out = 'How much wood could a woodchuck chuck':deflate(fixedCode=true)
			</p>

			The following example forces software compression:
			<p class="code">%out = 'How much wood could a woodchuck chuck':deflate(software=true)
	</p>		</p>

Tom at 13:03, 19 May 2026

2026-05-19T13:03:33Z

← Older revision		Revision as of 13:03, 19 May 2026
Line 19:		Line 19:
	<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.		<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.
	</ul>		</ul>
	The default value for this argument is <var>False</var> (use dynamic compression).</td></tr>		The default value for this argument is <var>False</var> (use dynamic compression).
			</td></tr>

	<tr><th><var>LazyMatch</var></th>		<tr><th><var>LazyMatch</var></th>
	<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.		<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.
	The default value for this argument is <var>False</var> (do not use "lazy match" compression).</td></tr>		The default value for this argument is <var>False</var> (do not use "lazy match" compression).
			<p><b>Note:</b> This parameter has no effect when hardware compression is used (see [[#Hardware vs. software compression\|Hardware vs. software compression]]).</p>
			</td></tr>

	<tr><th><var>MaxChain</var></th>		<tr><th><var>MaxChain</var></th>
	<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.		<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.
	The default value for this argument is 0. If specified, it must be between 0 and 99, inclusive.</td></tr>		The default value for this argument is 0. If specified, it must be between 0 and 99, inclusive.
			<p><b>Note:</b> This parameter has no effect when hardware compression is used (see [[#Hardware vs. software compression\|Hardware vs. software compression]]).</p>
			</td></tr>
	</table>		</table>

Line 33:		Line 38:
	<ul>		<ul>

	<li>The <var>[[NCMPBUF parameter\|NCMPBUF]]</var> parameter must be set to a		<li>The <var>[[NCMPBUF parameter\|NCMPBUF]]</var> parameter must be set to a non-0 value during <var class="product">Model 204</var> initialization to allow use of the <var>Deflate</var> function; otherwise, invoking <var>Deflate</var> causes request cancellation.
	non-0 value during <var class="product">Model 204</var>initialization to allow
	use of the <var>Deflate</var> function; ~~otherise~~, invoking <var>Deflate</var>
	causes request cancellation.

	<li>As with any compression scheme, it is possible that a particular string will become longer after compression. This would happen, for example, if a deflated string were passed to <var>Deflate</var>.		<li>As with any compression scheme, it is possible that a particular string will become longer after compression. This would happen, for example, if a deflated string were passed to <var>Deflate</var>.
Line 42:		Line 44:
	<li>Short strings (less than 128 bytes) typically compress better with <code>fixedCode=true</code>.		<li>Short strings (less than 128 bytes) typically compress better with <code>fixedCode=true</code>.
	</ul>		</ul>

			==Hardware vs. software compression==
			<p>[Introduced in Model 204 version 8.0]</p>

			<p>On IBM z15 and above processors, <var>Deflate</var> automatically uses the DFLTCC (Deflate Conversion Call) hardware instruction to perform compression. On older processors without DFLTCC support, the existing software implementation is used. The choice is made automatically and is transparent to the application.</p>

			<p>There are some behavioral differences between hardware and software compression that should be noted:</p>

			<ul>
			<li>The <var>LazyMatch</var> and <var>MaxChain</var> parameters are <b>ignored</b> when hardware compression is used. The DFLTCC hardware uses its own internal compression strategy for match searching, and these parameters have no effect. The <var>FixedCode</var> parameter <b>is</b> honored: when <code>fixedCode=true</code>, the hardware uses fixed Huffman codes; when <code>fixedCode=false</code> (the default), the hardware generates a Dynamic Huffman Table (DHT) from the input data for each deflate block.</li>

			<li>Hardware compression is <b>non-deterministic</b>: compressing the same input data multiple times may produce different compressed output, even with identical parameters. This is because the DFLTCC instruction uses an implementation-dependent hash function for duplicate string matching, as documented in the z/Architecture Principles of Operation. The compressed output is always valid RFC 1951 data and can be decompressed by <var>[[Inflate (String function)\|Inflate]]</var> regardless, but applications should not depend on a specific compressed length or byte-for-byte reproducibility of compressed data.</li>

			<li>Hardware compression generally provides significantly better throughput than software compression, particularly for larger input data.</li>
			</ul>

			<p>These differences also apply to the <var>[[Gzip (String function)\|Gzip]]</var> and <var>[[Zip (String function)\|Zip]]</var> methods, which use <var>Deflate</var> compression internally.</p>

	==Examples==		==Examples==
Line 51:		Line 70:
	<ul>		<ul>
	<li><var>[[Inflate (String function)\|Inflate]]</var> is used to decompress the string to its original value.		<li><var>[[Inflate (String function)\|Inflate]]</var> is used to decompress the string to its original value.
	<li>Other related methods:		<li>Other related methods:
	<ul>		<ul>
	<li><var>[[Gunzip (String function)\|Gunzip]]</var>		<li><var>[[Gunzip (String function)\|Gunzip]]</var>

ELowell at 21:00, 3 September 2015

2015-09-03T21:00:21Z

← Older revision		Revision as of 21:00, 3 September 2015
Line 1:		Line 1:
	{{Template:String:Deflate subtitle}}		{{Template:String:Deflate subtitle}}

	This function compresses a longstring using the "deflate" algorithm. The deflate algorithm is described completely in RFC 1951. It is very effective with HTML and XML data.		This function compresses a longstring using the "deflate" algorithm. The deflate algorithm is described completely in RFC 1951. It is very effective with HTML and XML data.

Line 8:		Line 7:
	===Syntax terms===		===Syntax terms===
	<table class="syntaxTable">		<table class="syntaxTable">
	<tr><th>%outString</th>		<tr><th nowrap>%outString</th>
	<td>The resulting compressed string.</td></tr>		<td>The resulting compressed string.</td></tr>

Line 61:		Line 60:
	</ul>		</ul>
	</ul>		</ul>


	{{Template:String:Deflate footer}}		{{Template:String:Deflate footer}}

JAL2: /* Syntax terms */

2012-08-09T18:37:08Z

Syntax terms

← Older revision		Revision as of 18:37, 9 August 2012
Line 15:		Line 15:

	<tr><th><var>FixedCode</var></th>		<tr><th><var>FixedCode</var></th>
	<td><var>FixedCode</var> is an optional, name required, parameter that is a <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> value that specifies whether the compression uses fixed codes or is dynamic, based on the contents of the input <var class="term">string</var>.		<td><var>FixedCode</var> is an optional, [[Notation conventions for methods#Named parameters\|name required]], parameter that is a <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> value that specifies whether the compression uses fixed codes or is dynamic, based on the contents of the input <var class="term">string</var>.
	<ul>		<ul>
	<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but they slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.		<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but they slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.

JAL2: /* See also */

2012-08-09T18:28:47Z

JAL2: /* See also */

2012-08-09T17:59:27Z

JAL2: /* See also */

2012-08-09T17:54:36Z

JAL2: /* Usage notes */

2012-07-31T22:12:35Z

Usage notes

← Older revision		Revision as of 22:12, 31 July 2012
Line 33:		Line 33:
	==Usage notes==		==Usage notes==
	<ul>		<ul>

	<li>The <var>[[NCMPBUF parameter\|NCMPBUF]]</var> parameter must be set to a		<li>The <var>[[NCMPBUF parameter\|NCMPBUF]]</var> parameter must be set to a
	non-0 value during <var class="product">Model 204</var>initialization to allow		non-0 value during <var class="product">Model 204</var>initialization to allow
	use of the <var>Deflate</var> function; otherise, invoking <var>Deflate</var>		use of the <var>Deflate</var> function; otherise, invoking <var>Deflate</var>
	causes request cancellation.		causes request cancellation.
	<li>As with any compression scheme, it is possible that a particular string will become longer after compression. This would happen, for example, if a deflated string were passed to $Deflate.
			<li>As with any compression scheme, it is possible that a particular string will become longer after compression. This would happen, for example, if a deflated string were passed to <var>Deflate</var>.

	<li>Short strings (less than 128 bytes) typically compress better with <code>fixedCode=true</code>.		<li>Short strings (less than 128 bytes) typically compress better with <code>fixedCode=true</code>.
	</ul>		</ul>

JAL2: /* Syntax terms */

2012-07-31T22:11:01Z

Syntax terms

JAL2: /* Syntax terms */

2012-07-31T22:03:22Z

Syntax terms

← Older revision		Revision as of 22:03, 31 July 2012
Line 15:		Line 15:

	<tr><th><var>FixedCode</var></th>		<tr><th><var>FixedCode</var></th>
	<td><var>FixedCode</var> is an optional, name required, <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> parameter that is a <var>Boolean</var> value that specifies whether the compression uses fixed codes		<td><var>FixedCode</var> is an optional, name required, <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> parameter that is a <var>Boolean</var> value that specifies whether the compression uses fixed codes or is dynamic, based on the contents of the input <var class="term">string</var>.
	or is dynamic, based on the contents of the input <var class="term">string</var>.
	<ul>		<ul>
	<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.		<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.

← Older revision		Revision as of 18:28, 9 August 2012
Line 58:		Line 58:
	<li><var>[[GunzipFilename (String function)\|GunzipFilename]]</var>		<li><var>[[GunzipFilename (String function)\|GunzipFilename]]</var>
	<li><var>[[Gzip (String function)\|Gzip]]</var>		<li><var>[[Gzip (String function)\|Gzip]]</var>
			<li><var>[[Zip (String function)\|Zip]]</var>
	</ul>		</ul>
	</ul>		</ul>

← Older revision		Revision as of 17:59, 9 August 2012
Line 55:		Line 55:
	<ul>		<ul>
	<li><var>[[Gunzip (String function)\|Gunzip]]</var>		<li><var>[[Gunzip (String function)\|Gunzip]]</var>
			<li><var>[[GunzipDatetimeNS (String function)\|GunzipDatetimeNS]]</var>
			<li><var>[[GunzipFilename (String function)\|GunzipFilename]]</var>
	<li><var>[[Gzip (String function)\|Gzip]]</var>		<li><var>[[Gzip (String function)\|Gzip]]</var>
	</ul>		</ul>

← Older revision		Revision as of 17:54, 9 August 2012
Line 52:		Line 52:
	<ul>		<ul>
	<li><var>[[Inflate (String function)\|Inflate]]</var> is used to decompress the string to its original value.		<li><var>[[Inflate (String function)\|Inflate]]</var> is used to decompress the string to its original value.
	<li>Other related methods: [[??]]		<li>Other related methods:
			<ul>
			<li><var>[[Gunzip (String function)\|Gunzip]]</var>
			<li><var>[[Gzip (String function)\|Gzip]]</var>
	</ul>		</ul>
			</ul>


	{{Template:String:Deflate footer}}		{{Template:String:Deflate footer}}

← Older revision		Revision as of 22:11, 31 July 2012
Line 15:		Line 15:

	<tr><th><var>FixedCode</var></th>		<tr><th><var>FixedCode</var></th>
	<td><var>FixedCode</var> is an optional, name required, <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]~~</var> parameter that is a <var>Boolean~~</var> value that specifies whether the compression uses fixed codes or is dynamic, based on the contents of the input <var class="term">string</var>.		<td><var>FixedCode</var> is an optional, name required, parameter that is a <var>[[Boolean_enumeration#Using_Boolean_enumerations\|Boolean]]</var> value that specifies whether the compression uses fixed codes or is dynamic, based on the contents of the input <var class="term">string</var>.
	<ul>		<ul>
	<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.		<li>With fixed code compression (<code>fixedCode=true</code>), the tables used for compression (defined as part of RFC 1951) are somewhat optimized for ASCII character data, but they slightly decrease the amount of CPU required to perform compression. Also, since the codes are already defined as part of the specification, they are not included in the compressed data.
	<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.		<li>With dynamic compression (<code>fixedCode=false</code>), the compression code tables are generated based on the input data. Dynamic tables typically provide somewhat better compression on most types of data. There is a very slight CPU overhead in computing the frequencies of byte values in the input data. Also, since the code tables are dynamic, they are included as part of the compressed data. This will increase the size of the compressed longstring, but these tables are small, since they are also stored in a compressed form.
	</ul>		</ul>
Line 24:		Line 24:
	<tr><th><var>LazyMatch</var></th>		<tr><th><var>LazyMatch</var></th>
	<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.		<td><var>LazyMatch</var> is an optional, name required, parameter that is a <var>Boolean</var> value that specifies whether to use "lazy match" compression, as specified in RFC 1951.
	~~This argument is optional; its~~ default value is <~~code~~>~~false~~</~~code~~> (do not use "lazy match" compression).</td></tr>		The default value for this argument is <var>False</var> (do not use "lazy match" compression).</td></tr>

	<tr><th><var>MaxChain</var></th>		<tr><th><var>MaxChain</var></th>
	<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.		<td><var>MaxChain</var> is an optional, name required, parameter that is a numeric value that specifies the maximum hash chain length, as explained in RFC 1951.
	~~This argument is optional; its~~ default value is 0. If specified, it must be between 0 and 99, inclusive.</td></tr>		The default value for this argument is 0. If specified, it must be between 0 and 99, inclusive.</td></tr>
	</table>		</table>