Release notes for Model 204 version 7.7: Difference between revisions
m (→Fast/Unload enhancements: add link) |
|||
(256 intermediate revisions by 12 users not shown) | |||
Line 1: | Line 1: | ||
These release notes list the enhancements and other changes contained in Model 204 version 7.7 | These release notes list the enhancements and other changes contained in Model 204 version 7.7. | ||
==Overview== | ==Overview== | ||
Line 9: | Line 5: | ||
Before beginning your installation, please read through this information about product installation and changes. | Before beginning your installation, please read through this information about product installation and changes. | ||
==New features== | ==New in this release== | ||
The table below cites some highlights of Model 204 version 7.7. For a full list of features, refer to the Table of Contents. | |||
<table> | |||
<tr class="head"><th>Category</th> | |||
<th>Feature</th></tr> | |||
<tr> | |||
<td>Performance</td> | |||
<td> | |||
<ul> | |||
<li>Continued expansion of 64-bit addressability. See [[#Elimination of BTB buffers|Elimination of BTB buffers]]. </li> | |||
<li>Greater zIIP processor availability: M204 HPO and Fast/Unload HPO. See [[#zIIP exploitation|zIIP exploitation]]. </li> | |||
<li>zIIP load tuning. See [[#MPDELAY and MPDELAYZ (new)|MPDELAYZ]], [[#SCHDOFLS (new)|SCHDOFLS]], [[#SCHDOPT (change to X'20' bit processing)|SCHDOPT]]. </li> | |||
<li>Essential removal of application limits on the [[#Increase in request limit for number of images, screens, and menus|number of images, screens, and menus]].</li> | |||
<li>Support for large data sets (as many as 16 million tracks) for the Model 204 Checkpoint facility [[Checkpoints: Storing before-images of changed pages#Creating the CHKPOINT.2FCHKPNT .28and CHKPNTS.29 data set|CHKPOINT or CHKPNTS data sets]]. See [[System_and_media_recovery#ROLL_BACK_processing.2C_Pass_2|ROLL BACK processing, Pass 2]].</li> | |||
</ul> | |||
</td></tr> | |||
<tr> | |||
<td>Security</td> | |||
<td> | |||
<ul> | |||
<li>Stronger cryptographic algorithms: SHA-384, SHA-512. See [[#"SSL" String methods|"SSL" String methods]], [[#New DigestAlgorithm values|New DigestAlgorithm values]], and [[#New default certificate-signing algorithm|New default certificate-signing algorithm]]. </li> | |||
<li>Longer RSA keys (as many as 4096 bits). See [[#Janus Network Security ciphers and private keys|Janus Network Security ciphers and private keys]]. </li> | |||
<li>Support for [[#Long password support|longer and mixed-case login passwords]]. </li> | |||
</ul> | |||
</td><tr> | |||
<tr> | |||
<td nowrap>Add-on enhancements</td> | |||
<td> | |||
<ul> | |||
<li>A more versatile Fast/Unload through [[#Integration of Fast/Unload with the Online load module|integration with Model 204]]. </li> | |||
<li>Janus products' [[#Support for IPV6|support for the IPV6 network protocol]], expanding the network address space from 32 to 128 bits. </li> | |||
</ul> | |||
</table> | |||
==Operating system and hardware requirements== | |||
===Operating system requirements=== | |||
<ul> | |||
<li><b>IBM z/OS versions supported:</b> | |||
<ul> | |||
<li>All IBM supported releases up to and including z/OS 3.1. <br />(For z/OS 2.2, see [[IBM z/OS 2.2 PTF requirement]].)</li> | |||
<p>Version 1.07 is sufficient for all functionality except for the following features:</p> | |||
<ul> | |||
<li>zHPF support requires version [[IBM z/OS 2.1 compatibility issue|2.1]].</li> | |||
<li>Large (1 MB) page support requires version 1.9.</li> | |||
<li>Extended address volumes (EAV) requires version 1.12.</li> | |||
</ul> | |||
</li> | |||
</ul> | |||
On z/OS, Model 204 release 7.7 operates as an APF authorized load module, as required by many 7.7 features. <br /> | |||
To run Model 204 unauthorized, [[Contacting Rocket Software Technical Support|contact Technical Support]]. | |||
<li><b>IBM z/VM versions supported:</b> | |||
<ul> | |||
<li>All IBM supported releases up to and including z/VM 7.3.</li> | |||
</ul> | |||
</li> | |||
<li><b>IBM z/VSE versions supported:</b> | |||
<ul> | |||
<li>All IBM supported releases up to and including z/VSE 6.1.</li> | |||
</ul> | |||
</li> | |||
</ul> | |||
===Hardware requirements=== | |||
In general, Model 204 version 7.7 requires the IBM z/890 or above processor. | |||
<p>However, the IBM z10 or above processor is required for the following features: | |||
<ul> | |||
<li>large (1 MB) page support</li> | |||
<li>IBM's High Performance FICON (zHPF) support</li> | |||
</ul></p> | |||
===Model 204 compatibility with operating systems=== | |||
For information on Model 204 certification with IBM operating systems, see [[Model 204 system requirements]]. | |||
===Connect<sup>★</sup> compatibility with Model 204=== | |||
Connect<span class="superstar">★</span> version 7.5 or 7.7 is compatible with Model 204 version 7.7. | |||
For more information on Connect<span class="superstar">★</span> installation, see the [[:Category:Connect*|Connect<span class="superstar">★</span> wiki pages]]. | |||
==SOUL (User Language) enhancements== | |||
===New and changed classes and methods=== | |||
====New exception class: WriteError==== | |||
<var>[[WriteError class|WriteError]]</var> exceptions are thrown by the <var>Close</var>, <var>WriteBlock</var>, <var>WriteRecord</var>, and <var>WriteRecords</var> methods in the [[Dataset class]] if they encounter a full output <var>Dataset</var> object. | |||
====New default certificate-signing algorithm==== | |||
[[Janus Network Security]] as well as the <var>[[Stringlist_class|StringList]]</var> methods <var>[[AppendSignedCertificate (Stringlist function)|AppendSignedCertificate]]</var> and <var>[[AppendSignedClientCertificate (Stringlist function)|AppendSignedClientCertificate]]</var> methods have changed their default signature algorithm from SHA-1 to SHA-256. | |||
This change is propagated by zap maintenance to versions 7.6 and 7.5 of Model 204. | |||
===="SSL" String methods==== | |||
These new methods are added: | |||
<table> | |||
<tr class="head"><th>Method</th><th>Description</th></tr> | |||
<tr><td>[[SHA384digest (String function)|SHA384digest]]</td><td>SHA-384 digest</td></tr> | |||
<tr><td>[[SHA512digest (String function)|SHA512digest]]</td><td>SHA-512 digest</td></tr> | |||
</table> | |||
====New LoadMsgctl method==== | |||
The new <var>[[LoadMsgctl (XmlDoc subroutine)|LoadMsgctl]]</var> method lets you view what <var class="product">Model 204</var> messages have been affected by <var>[[MSGCTL command|MSGCTL]]</var> commands. The method also displays the current attributes of those messages. <!-- PDS-6119 --> | |||
In addition, to better understand the effect of the <var>MSGCTL</var> command, the [[RKTools]] <code>SIRIUS</code> file will contain a procedure you can use to display the <var>MSGCTL</var> commands that have been specified in the Online session. | |||
====New DigestAlgorithm values==== | |||
Values <var>SHA384</var> and <var>SHA512</var> are added to the [[DigestAlgorithm enumeration]]. | |||
====Method variable invocation==== | |||
[[Method variables]] can now be invoked using <code>%var()</code> or <code>%obj:var()</code>, as in JavaScript. | |||
====X509CertificateToXmlDoc method support for unknown elements==== | |||
A certificate's <code><RelativeDistinguishedName></code> element can contain a wide variety of attributes that <var>X509CertificateToXmlDoc</var> does not understand. Under Model 204 7.6 and earlier, this results in a parse exception, but under 7.7 and later, such attributes are added as <code><unknown></code> elements with an <code><ObjectIdentifier></code> element that indicates the ASN.1 object identifier. | |||
<p class="note"><b>Note:</b> You are advised not to refer to such an <code><unknown></code> element in your programs, since future updates to the <var>X509CertificateToXmlDoc</var> method might add support for the element, in which case the element name will change to a proper name. If such an element is of interest, [[Contacting Rocket Software Technical Support|contact Rocket Software technical support]]. </p> | |||
====Resulting element length in "ToXmlDoc" String methods==== | |||
Prior to version 7.7 of Model 204, the <var>[[DerToXmlDoc (String function)|DerToXmlDoc]]</var>, <var>[[X509CertificateToXmlDoc (String function)|X509CertificateToXmlDoc]]</var>, <var>[[X509CrlToXmlDoc (String function)|X509CrlToXmlDoc]]</var>, and | |||
<var>[[RSAPrivateKeyToXmlDoc (String function)|RSAPrivateKeyToXmlDoc]]</var> methods failed if input to them created any element in the result <var>XmlDoc</var> with a text child whose length exceeded 650 characters. | |||
An example of such input is a 4096-bit key (which requires 1024 hex characters). | |||
As of version 7.7, the lengths of the created text nodes are not restricted. | |||
====LDAP request length limit==== | |||
Prior to version 7.7 of Model 204, the SOUL [[LDAP class#limit|LDAP client buffers]] allowed a limit of 6144 bytes per request. As of 7.7, the limit is increased to 8184. | |||
===New XHTML entities for square-bracket characters=== | |||
<b>[</b> and <b>]</b> are newly supported as [[XML processing in Janus SOAP#Entity references|XMHTL entities]] (notably in the [[U (String function)#brackets|U method]]). This provides a better approach to specifying square brackets (such as for [[XPath#Some notes on XPath usage|XPath]] expressions) than the formerly recommended use of <var>Static</var> %variables initialized to the correct values. | |||
This change is propagated by zap maintenance to version 7.6 of Model 204. | |||
For example, to produce an XPath expression equivalent to the following: | |||
<p class="code"><nowiki>*/pers[@name="Hector"] </nowiki></p> | |||
Code like this was recommended under version 7.5 of Model 204: | |||
<p class="code">%lsq is string len 1 static initial('&#x5B;'):u | |||
%rsq is string len 1 static initial('&#x5D;'):u | |||
. . . | |||
%myXmldoc:print('*/pers' %lsq '@name="Hector"' %rsq) </p> | |||
Under version 7.6 and above, you can instead use the new entities and avoid the declarations, concatenations, and runtime conversions required above: | |||
<p class="code">%myXmldoc:print('*/pers<b>[</b>@name="Hector"<b>]</b>':u)</p> | |||
===Procedure names can begin with zero=== | |||
Formerly, a procedure name was not allowed to begin with a zero or a minus sign. As of version 7.7, a procedure name can begin with a zero, and alphanumeric procedure names can begin with a minus sign (<tt>-</tt>), which is interpreted as a hyphen. For example, <code>00123</code>, <code>-1myproc</code>, and <code>-myproc</code> are valid procedure names. | |||
<p> | |||
See the <var>[[PROCEDURE command|PROCEDURE]]</var> command for details. </p> | |||
===Assert statement support for Info expressions=== | |||
The SOUL <var>[[Assert statement|Assert]]</var> statement allows the optional parameter <var>Info</var> to provide additional output information. As of version 7.7, the <var>Info</var> phrase may contain any valid SOUL expression, including a method call or $function. The expression, which must be enclosed in parentheses, is evaluated only in the case of an <var>Assert</var> failure. | |||
A simple example is: | |||
<p class="code">assert %x gt 0, info ('abc' with 'def') </p> | |||
<blockquote class="note"> | |||
<p><b>Note:</b> This enhancement introduces a slight backward incompatibility: An <var>Assert</var> statement like the following, whose <var>Info</var> value begins with an opening parenthesis but has no closing parenthesis, compiled without error prior to version 7.7: </p> | |||
<p class="code">assert %x gt 0, info (</p> | |||
<p> | |||
From 7.7 on, such a statement produces a compilation error, because the compiler expects an expression after the open parenthesis. </p> | |||
</blockquote> | |||
==Security enhancements== | |||
===Long password support=== | ===Long password support=== | ||
<p> | <p> | ||
Logon passwords, maintained in CCASTAT, can now contain | Logon passwords, maintained in CCASTAT, can now contain as many as 127 characters. | ||
<br />Also, passwords and passphrases can now contain one or more embedded spaces. (Leading and trailing spaces are stripped.)</p> | |||
<p> | |||
The long password feature includes support for: </p> | |||
<ul> | <ul> | ||
<li>LOGON command | <li><var>[[LOGIN or LOGON command|LOGON]]</var> command</li> | ||
<li>LOGCTL C USERID command</li> | <li><var>[[LOGINCP or LOGONCP command|LOGONCP]]</var> command, used to change a password</li> | ||
<li>$Sir_Login function</li> | |||
<li><var>[[LOGCTL command: Modifying user ID entries in the password table|LOGCTL C USERID]]</var> command</li> | |||
<li><var>[[$Sir_Login]]</var> function</li> | |||
<li>Mixed-case passwords (if the <var>[[CUSTOM parameter|CUSTOM]]</var> parameter includes the value 11)</li> | <li>Mixed-case passwords (if the <var>[[CUSTOM parameter|CUSTOM]]</var> parameter includes the value 11)</li> | ||
<li>CCASTAT data sets created with or without password expiration support</li> | |||
<li>[[Storing_security_information_(CCASTAT)|CCASTAT]] data sets created with or without password expiration support</li> | |||
<li>Long passwords (passphrases) for use with the following [[Security interfaces overview|external security interfaces]]: CA-ACF2 MVS, Security Server (formerly RACF), and CA-Top Secret</li> | |||
</ul> | </ul> | ||
This feature is available for logon passwords only | <p class="note"><b>Note:</b> This feature is available for logon passwords only; it does not apply to file passwords.</p> | ||
<p> | |||
No changes to CCASTAT and no new CCAIN parameters are required to enable long password support.</p> | |||
<p>In order to allow embedded blanks in passwords passed on [[IFSTRTN_(IFAM2)_(HLI_function)|IFSTRTN]] calls, a semicolon is required as the password delimiter and the <var>[[CUSTOM parameter|CUSTOM]]</var> parameter 24 value must be set.</p> | |||
==SOUL ( | For additional security enhancements in version 7.7, see [[#Janus Network Security ciphers and private keys|Janus Network Security ciphers and private keys]] as well as [[#"SSL" String methods|"SSL" String methods]], [[#New DigestAlgorithm values|New DigestAlgorithm values]], and [[#New default certificate-signing algorithm|New default certificate-signing algorithm]]. | ||
=== | ==Janus product enhancements== | ||
[[ | ===<b id="IPV6"></b>Support for IPV6=== | ||
As of version 7.7, customers can use the [[Janus products]] in an IPV6 (Internet Protocol Version 6) environment. Before this release, all Janus commands and parameters were able to accommodate IPV4 addresses only. IPV6 addresses expand the network address space from 32 to 128 bits. | |||
These parameters, commands, and functions support IPV6 under version 7.7 of Model 204: | |||
<table> | |||
<tr class="head"><th>Commands</th><th>System parameter</th><th>SOUL</th></tr> | |||
<tr><td nowrap> | |||
JANUS CLSOCK and JANUS SRVSOCK <br> | |||
JANUSDEBUG and JANUS WEB DEBUG <br> | |||
JANUS DEFINEIPGROUP <br> | |||
JANUS DEFINE BINDADDR <br> | |||
JANUS DISIPG <br> | |||
JANUS DISUSG <br> | |||
JANUS TRACE <br> | |||
JANUS WEB ALLOW | |||
</td> | |||
<td nowrap> | |||
TCPTYPE <br> | |||
(see [[#tcptype|TCPTYPE (new IPV6 values)]]) | |||
</td> | |||
<td nowrap> | |||
$Web_IPAddr <br> | |||
LocalHost (UdpSocket property) | |||
</td></tr> | |||
</table> | |||
===Janus Network Security ciphers and private keys=== | |||
Support for certificates signed using [[DigestAlgorithm_enumeration|SHA-384 and SHA-512]] are added to [[Janus Network Security]]. This makes it possible to generate certificates signed with these algorithms and to accept server or client certificates signed with these algorithms. | |||
In addition, support is added for RSA keys that are as many as 4096 bits in length. You can now generate and sign 4096-bit keys and use them in client and server certificates using <var class="product">Janus Network Security</var> application as well as its associated and related methods, including: | |||
<table> | |||
<tr class="head"><th>Class</th><th>Method</th></tr> | |||
<tr><td>System</td> | |||
<td><var>[[GeneratedPrivateKey (System function)|GeneratedPrivateKey]]</var></td></tr> | |||
<tr><td rowspan="4">Stringlist</td> | |||
<td><var>[[AppendCertificateRequest (Stringlist function)|AppendCertificateRequest]]</var></td></tr> | |||
<tr><td><var>[[AppendGeneratedPrivateKey (Stringlist subroutine)|AppendGeneratedPrivateKey]]</var></td></tr> | |||
<tr><td><var>[[AppendSignedCertificate (Stringlist function)|AppendSignedCertificate]]</var></td></tr> | |||
<tr><td><var>[[AppendSignedClientCertificate (Stringlist function)|AppendSignedClientCertificate]]</var></td></tr> | |||
<tr><td rowspan="4">String</td> | |||
<td><var>[[CertificateRequest (String function)|CertificateRequest]]</var> </td></tr> | |||
<tr><td><var>[[ClientCertificateRequest (String function)|ClientCertificateRequest]]</var> </td></tr> | |||
<tr><td><var>[[RSAPrivateKeyToXmlDoc (String function)|RSAPrivateKeyToXmlDoc]]</var> </td></tr> | |||
<tr><td><var>[[SignedCertificate (String function)|SignedCertificate]]</var> </td></tr> | |||
</table> | |||
===Janus Web Server rules=== | |||
The following changes have been made in version 7.7: | |||
<ul> | |||
<li>Janus Web used to automatically implement [[Defining Web rules#Notes|two web server ON rules]] to set up access to the Janus Web sample home page and to demonstration application procedures. These rules were removed in version 7.6 (by zap maintenance) and are not present in version 7.7.</li> | |||
<li>You can now substitute an HTTP method name in the command for a <var>JANUS WEB ON</var> rule. See [[#ON rules (method name substitution)|ON rules (method name substitution)]] for details.</li> | |||
<li>The automatic <var>[[JANUS WEB ALLOW]]</var> rule, which allowed any user to access the port without requiring a login, is changed <i>for non-SSL ports</i> to the following: | |||
<p class="code">JANUS WEB <i>portname</i> DISALLOW * | |||
</p> | |||
<p> | |||
This rule requires a system administrator to explicitly define <var>ALLOW</var> rules to enable users to access non-SSL ports. | |||
The rule applies (after zap 77Z088 in version 7.7, or after zap 76Z418 in version 7.6) unless overridden by user-added rules. | |||
</p> | |||
<blockquote class="note"> | |||
<p><b>Note:</b> With version 7.7 zap 77Z090 or version 7.6 zap 76Z420, you can make the default <var>ALLOW</var> rule as it was in version 7.5 and earlier (<code>ALLOW *</code>). To do so, turn on the 1 bit of the <var>[[WEBDFLT parameter|WEBDFLT]]</var> parameter: </p> | |||
<p class="code">RESET WEBDFLT=1</p> | |||
</blockquote></li> | |||
<li>As described below in [[#JANUS WEB (additional rule support)|JANUS WEB (additional rule support)]], the <var>JANUS WEB</var> command <var>ALLOW</var> and <var>DISALLOW</var> rules are updated to include support for RESTful and WebDAV HTTP methods. </li> | |||
</ul> | |||
===Janus Web access to HTTP authorization and authentication headers=== | |||
Under version 7.7, Janus Web lets you access HTTP user authentication headers. You can capture the HTTP "Authorization" request header value, and you can set the "WWW-Authenticate" response header. See [[Janus Web Server security#Authorization and WWW-Authenticate headers|Authorization and WWW-Authenticate headers]]. | |||
==Fast/Unload enhancements== | ==Fast/Unload enhancements== | ||
===Integration of Fast/Unload with the Online load module === | ===<b id="funldIntegrat"></b>Integration of Fast/Unload with the Online load module === | ||
Starting with version 7.7 of Model 204 | <!-- PDS-5869 --> | ||
Previously (for all versions of <var class="product">Fast/Unload</var> through 4.7), the standalone <code>FUNLOAD</code> load module was downloaded and linked separately and independently from Model 204. Starting with version 7.7 of Model 204: | |||
<ul> | |||
<li><var class="product">Fast/Unload</var> is entirely linked with the Model 204 Online load module. </li> | |||
<li>Maintenance zaps applied to the Online load module include all <var class="product">Fast/Unload</var> maintenance.</li> | |||
<li>The version number of <var class="product">Fast/Unload</var> is the same as the version number of Model 204. </li> | |||
<li>If you are authorized for Fast/Unload, the authorization zap for the ONLINE load module will contain authorization for Fast/Unload. The authorization zap used for previous releases of FUNLOAD should not be applied to the FUNLOAD module in 7.7.</li> | |||
</ul> | |||
Under 7.7, the Online load module can be linked with an ALIAS (the standard one is FUNLOAD) and an alternate ENTRY. This alias is functionally indistinguishable from the standalone <var class="product">Fast/Unload</var> FUNLOAD load module installed for all previous versions of <var class="product">Fast/Unload</var>. | |||
The integration of Fast/Unload with the Online load module also makes additional DDnames available to PGM=FUNLOAD for possible problem diagnosis by Rocket Technical Support. These DDnames are <code>CCASNAP</code>, <code>CCAAUDIT</code>, and <code>CCAPRINT</code>, and they are described in [[Fast/Unload invocation#ccadd|Fast/Unload invocation]]. | |||
A significant benefit of running Fast/Unload integrated with Model 204 and not standalone is the ability to take advantage of zIIP processing, as described next in the "zIIP exploitation" section. | |||
===zIIP exploitation=== | ===zIIP exploitation=== | ||
If you have an authorization zap that contains | If you have an authorization zap that contains both of the following, your standalone PGM=FUNLOAD jobs will run on a zIIP processor, if one is available: | ||
<ul> | |||
<li><var class="product">[[Performance monitoring and tuning#Offloading Model 204 work to zIIP processors|M204 HPO]]</var>, the zIIP-support product of Model 204 | |||
<p> | |||
PGM=FUNLOAD automatically supplies the necessary Model 204 parameters to enable zIIP exploitation. </p></li> | |||
<li>The <var class="product">[[Fast/Unload overview#fuhpo|Fast/Unload HPO]]</var> product </li> | |||
</ul> | |||
===New #VIEW204 function=== | |||
The <var>[[Fast/Unload standard functions#.23VIEW204: Value of Model 204 parameter|#VIEW204]]</var> function returns the value of the [[List of Model 204 parameters|Model 204 parameter]] you specify as an argument. | |||
===PUT statement enhancements=== | |||
<!-- PDS-6107 --> | |||
====Length prefix for PUT output values==== | |||
<!-- PDS-5871 --> | |||
New <var>[[Fast/Unload PUT statement#PUT|PUT]]</var> statement syntax is added to insert a one-byte or two-byte binary integer, containing the byte length of a <var>PUT</var> value, in the output stream before the value. | |||
For better readability and lower CPU cost than the techniques currently used to achieve the same result, the <var>AS</var> clause of a <var>PUT</var> statement will now allow the <var>COUNTED</var> keyword: | |||
<p class="code">... PUT <i>info</i> .. AS [<i>format</i>] COUNTED[1|2] </p> | |||
<p> | |||
For example, <code>PUT FIRST.NAME AS COUNTED2</code> puts the first occurrence of field <code>FIRST.NAME</code> as a string value, preceded by a two-byte binary integer containing the length of that occurrence.</p> | |||
<p> | |||
With this feature, you can replace FUEL code such as the following: </p> | |||
<p class="code">%VAL = ITEM.CODE(%OCC) | |||
%LEN = #LEN( %VAL ) | |||
PUT %LEN AS FIXED(2) | |||
PUT %VAL </p> | |||
<p>With: </p> | |||
<p class="code">PUT %VAL AS COUNTED2 </p> | |||
====#function as PUT "info" argument==== | |||
<!-- PDS-5871 --> | |||
New in this version, a #function call is allowed as the <var>PUT</var> <var class="term">info</var> argument. For example, instead of FUEL code such as the following: | |||
<p class="code">%VAL = #STRIP(ITEM.VALUE(%OCC), 'L', 0) | |||
PUT %VAL </p> | |||
You can use this more readable and somewhat more efficient equivalent: | |||
<p class="code">PUT #STRIP(ITEM.VALUE(%OCC), 'L', 0) </p> | |||
===#STRIP function enhancements=== | |||
<!-- PDS-5871 --> | |||
=== | ====New #STRIP fourth argument==== | ||
<!-- PDS-5871 --> | |||
The new fourth argument of <var>[[Fast/Unload standard functions##strip|#STRIP]]</var> lets you designate a <var>#STRIP</var> first-argument value to be nullified. That is, when the value of the first argument is equal to the value of the fourth argument, <var>#STRIP</var> returns a null string. You might use this optional argument for fields that have a "placeholder value" or "default value" which is not actual data. | |||
This argument can be conveniently combined with the | |||
new <var>[[#Length prefix for PUT output values|COUNTED]]</var> options for <var>PUT</var>, because a length-prefixed format allows a reliable, unambiguous representation of a series of null strings. | |||
<p> | |||
Combining the new fourth argument, the new <var>COUNTED2</var> option, and the new [[#optn|N option]] of the second argument provides a simpler alternative to FUEL code such as the following:</p> | |||
<p class="code">%VAL = ITEM.STRING(%OCC) | |||
IF %VAL EQ '_' THEN | |||
PUT 0 AS FIXED(2) | |||
ELSE | |||
%LEN = #LEN(%VAL) | |||
PUT %LEN AS FIXED(2) | |||
PUT %VAL | |||
END IF | |||
</p> | |||
<p> | |||
You can replace the above statements by the more readable and efficient: </p> | |||
<p class="code">PUT #STRIP(ITEM.STRING(%OCC), 'N', , '_') AS COUNTED2 | |||
</p> | |||
====New #STRIP type options==== | |||
<!-- PDS-5871 --> | |||
<var>P</var> and <var>N</var> strip-type options are added to the <var>#STRIP</var> function: | |||
<ul> | |||
<li>The new <var>P</var> option strips all but one leading <var class="term">pad</var>-argument characters from the <var>#STRIP</var> first argument returned value, if that value contains a non-zero length string of only <var class="term">pad</var> characters. | |||
<p> | |||
<var>P</var>, together with other new Fast/Unload <var>PUT</var> features, provides a simpler alternative to FUEL code such as the following:</p> | |||
<p class="code">%VAL = ITEM.NUMBER(%OCC) | |||
IF %VAL EQ '_' OR %VAL EQ '' THEN | |||
PUT 0 AS FIXED(2) | |||
ELSE | |||
%VAL = #STRIP(%VAL, 'L', '0') | |||
IF %VAL EQ '' THEN | |||
%VAL = '0' | |||
END IF | |||
%LEN = #LEN(%VAL) | |||
PUT %LEN AS FIXED(2) | |||
PUT %VAL | |||
END IF </p> | |||
<p> | |||
You can replace the above statements with the following, which outputs a numeric value with leading zeroes stripped: </p> | |||
<p class="code">PUT #STRIP(ITEM.NUMBER(%OCC), 'P', '0', '_') AS COUNTED2 | |||
</p> | |||
<p class="note"><b>Note:</b> A FUEL <var>IF</var> statement oddity is that the precedence of <var>AND</var> and <var>OR</var> are the same.</p></li> | |||
<li id="optn">The new <var>N</var> option strips neither leading-characters nor trailing-characters. | |||
<p> | |||
For an example, see [[#New #STRIP fourth argument|New #STRIP fourth argument]], above.</p></li> | |||
</ul> | |||
==New and changed commands== | ==New and changed commands== | ||
Line 46: | Line 417: | ||
****************************************************************** | ****************************************************************** | ||
--> | --> | ||
===AUTHCTL VIEW (additional information displayed)=== | |||
The <var>[[AUTHCTL command#Example|AUTHCTL]]</var> command output now includes a list of the available sets of control parameters for the external security interface you specify in the command. | |||
===DISPLAY MODMAP (new parameter: <var>UEX</var>)=== | |||
The <var>[[DISPLAY MODMAP command|DISPLAY MODMAP]]</var> command now has a <var>UEX</var> parameter that displays the entry point addresses of all defined user exits. | |||
===FREE command (new message)=== | |||
Prior to this release, a successful <var>[[FREE command#msg|FREE]]</var> command was not followed by a message indicating success. Under version 7.7, <var>FREE</var> now indicates success with the following message: | |||
<p class="code">M204.0510: FREE command successful; <i>ddname</i> freed </p> | |||
Also new in this release, a <var>FREE</var> command that takes no action because the specified file does not exist or is not allocated is now followed by an explanatory message: | |||
<p class="code">M204.0509: No action taken by FREE command; <i>ddname</i> not allocated </p> | |||
<p> | |||
In earlier versions, no such message followed. </p> | |||
===JANUS DEFINE (new parameter: <var>SSLTRUST</var>)=== | |||
The <var>[[JANUS DEFINE]]</var> command now has an <var>[[SSLTRUST (JANUS DEFINE parameter)|SSLTRUST]]</var> parameter that indicates that the certificate presented by the other side of a TLS/SSL connection is to be accepted even if it is not signed by a known certifying authority. | |||
===JANUS WEB (additional rule support)=== | |||
<!-- PDS-5984 --> | |||
====Expanded ALLOW/DISALLOW rules==== | |||
The <var>[[JANUS WEB]]</var> command <var>ALLOW</var>/<var>DISALLOW</var> rules are updated to include support for these HTTP methods: | |||
<ul> | |||
<li>The RESTful ([https://en.wikipedia.org/wiki/Representational_state_transfer Representational State Transfer]) methods CONNECT, DELETE, OPTIONS, PATCH, and TRACE. </li> | |||
<li>The WebDAV ([http://www.webdav.org/specs/rfc4918.html Distributed Authoring and Versioning]) methods PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. </li> | |||
</ul> | |||
====ON rules (method name substitution)==== | |||
In a version 7.7 <var>[[JANUS WEB ON|JANUS WEB ON]]</var> command, you can now reference the name of the HTTP method that is associated with the incoming request. To do this, specify an <code>M</code> after the escape (<tt>"</tt>) character, as in: | |||
<p class="code">JANUS WEB WEBPORT ON /TEST/* OPEN FILE TEST CMD 'I "M.*'</p> | |||
A GET request for URL <code>/test/foo</code> would result in the file <code>TEST</code> being opened and the command <code>I GET.FOO</code> being issued. A POST for the same URL would result in the command <code>I POST.FOO</code> being issued. | |||
<p class="note"><b>Note:</b> This behavior is a change from past releases, when <code>"M</code> was simply converted to <code>M</code>.</p> | |||
===LOGINCP or LOGONCP (new)=== | |||
Because colons are now valid password characters, the <var>[[LOGINCP or LOGONCP command|LOGINCP]]</var> (LOGIN and Change Password) command replaces the former technique for changing passwords using <var>LOGIN</var>. | |||
<p>Before version 7.7, with <var>LOGIN</var>, you specified <var class="term">oldpassword</var><tt>:</tt><var class="term">newpassword</var> in response to the <code>M204.0347: Password</code> prompt.</p> | |||
With the <var>LOGINCP</var> command, you are prompted and re-prompted for the new password after successful logon: | |||
<p class="code"><b>LOGINCP USER1</b> | |||
M204.0347: Password | |||
M204.0353: USER1 USER1 login 16 JUL 29 12.38 | |||
M204.2633: Enter new password | |||
M204.2633: Re-enter new password | |||
M204.0350: New password accepted | |||
M204.0345: CCASTAT updated | |||
</p> | |||
<var>LOGONCP</var> is a synonym for <var>LOGINCP</var>. | |||
===ZHPF (new parameters: <i>filename</i> and *)=== | ===ZHPF (new parameters: <i>filename</i> and *)=== | ||
The <var>[[ZHPF command|ZHPF]]</var> command checks zHPF ability for the file currently opened by the user. | The <var>[[ZHPF command|ZHPF]]</var> command checks zHPF ability for the file currently opened by the user. | ||
As of 7.7, you can specify parameters to <var>ZHPF</var>: | As of Model 204 7.7, you can specify parameters to <var>ZHPF</var>: | ||
< | <ul> | ||
< | <li><var class="term">filename</var>, to check a specific file</li> | ||
<li>An asterisk (<tt>*</tt>), to check local files opened by all users</li> | |||
</ul> | |||
==New and changed parameters== | ==New and changed parameters== | ||
Line 60: | Line 487: | ||
--> | --> | ||
===CUSTOM (new values)=== | ===CUSTOM (new and changed values)=== | ||
The following values have been added to the <var>[[ | ====New values==== | ||
The following values have been added to the <var>[[CUSTOM parameter|CUSTOM]]</var> parameter in this release: | |||
<ul> | <ul> | ||
<li>The CUSTOM=23 value always truncates the | <li>The <code>CUSTOM=23</code> value always truncates the user ID to 10 characters.</li> | ||
<li>The <code>CUSTOM=41</code> value allows recording of data on successful RACF user logins. The login data is shown in RACFRW batch reports.</li> | |||
<li>The <code>CUSTOM=42</code> value allows the editing of procedure names containing the following special characters: comma, equal sign, space, single quote, semicolon.</li> | |||
</ul> | |||
<li>The CUSTOM= | ====Changed value==== | ||
<ul> | |||
<li>The <code>CUSTOM=11</code> value also supports special-characters for RACF passwords as of version 7.7.</li> | |||
</ul> | </ul> | ||
==Performance | ===LFSCB (new default/minimum value)=== | ||
The default (and minimum) value of <var>[[LFSCB parameter|LFSCB]]</var> is now 8 bytes. | |||
===LITBL (new default/minimum value)=== | |||
The default (and minimum) value of <var>[[LITBL parameter|LITBL]]</var> is now 8 bytes. | |||
===MINDEBCL (new)=== | |||
The new system parameter, <var>[[MINDEBCL parameter|MINDEBCL]]</var>, can be set in an Online to specify the minimum [[Debugger]] Client build number that can be used with that Online. | |||
===MPDELAY and MPDELAYZ (new)=== | |||
For an [[Performance monitoring and tuning#Multiprocessing .28MP.2F204.29|MP/204]] Online, the <var>[[MPDELAY parameter|MPDELAY]]</var> and <var>[[MPDELAYZ parameter|MPDELAYZ]]</var> parameters are added to improve the efficiency of the MP scheduler. They reduce the cost of starting too many new subtasks for the amount of work to be done. | |||
===NUMBUF and NUMBUFG=== | |||
As described below in [[#Elimination of BTB buffers|Elimination of BTB buffers]], setting <var>NUMBUFG</var> greater than 0 in version 7.7 forces <var>NUMBUF</var> to 0 (no buffer pool buffers reside below the bar). Not setting <var>NUMBUFG</var> or setting it to 0 (no buffers above the bar) allows the calculation of BTB buffers to remain as in previous versions. | |||
===SCHDOFL and SCHDOFLZ (new minimum value)=== | |||
The new minimum value of <var>[[SCHDOFL parameter|SCHDOFL]]</var> and <var>[[SCHDOFLZ parameter|SCHDOFLZ]]</var> is 0. Before Model 204 7.7, their minimum allowed value was 1. | |||
===SCHDOFLS (new)=== | |||
For z/OS system customers using <var class="product">Model 204</var> zIIP support, the new <var>[[SCHDOFLS parameter|SCHDOFLS]]</var> system parameter helps you to regulate the zIIP processor workload. | |||
<var>SCHDOFLS</var> specifies both of the following: | |||
<ul> | |||
<li>The target number of threads on the zIIP offload queue before a non-SRB MP subtask is dispatched to help the zIIP subtasks. </li> | |||
<li>If started, how aggressively non-SRB MP subtasks pick up work from the zIIP offload queue. </li> | |||
</ul> | |||
<p> | <p> | ||
This parameter applies to z/OS only.</p> | |||
===SCHDOPT (change to X'20' bit processing)=== | |||
The <var>[[SCHDOPT parameter|SCHDOPT]]</var> X'20' bit prevents the maintask from running work that is intended to run on a zIIP subtask (when zIIP subtasks are defined and activated). As of Model 204 7.7, even when this bit is off, the maintask will run some of the zIIP work only if the zIIP subtasks appear to be saturated. Saturation is defined as a zIIP subtask queue length of at least <code>[[SCHDOFLZ parameter|SCHDOFLZ]]*[[AMPSUBZ parameter|AMPSUBZ]]</code>. | |||
Formerly, this saturation requirement was absent, allowing the maintask to take on more (possibly too much) of the zIIP workload. | |||
===SERVSIZE (new default/minimum value)=== | |||
The minimum value for <var>[[SERVSIZE parameter|SERVSIZE ]]</var> is changed from zero to 65536. If <var>SERVSIZE</var> is explicitly set in CCAIN and its value is less than 64K, the following message is issued: | |||
<p class="code">M204.1149: SERVSIZE has been set to its minimum value: 65536 | |||
</p> | |||
If <var>SERVSIZE</var> was not set but was [[Defining the runtime environment (CCAIN)#Sizing user server areas|calculated by the system]] to a value less than 64K, the following message is issued: | |||
<p class="code">M204.0163: SERVSIZE increased to 65536 | |||
</p> | |||
<p> | <p> | ||
This change is propagated by zap maintenance to versions 7.6, 7.5, and 7.4 of Model 204. </p> | |||
<p> | |||
===<b id="tcptype"></b>TCPTYPE (new IPV6 values)=== | |||
< | As part of the version 7.7 [[#IPV6|support for IPV6]], three new optional (IPV6-address-only) values are added to the <var>[[TCPTYPE parameter|TCPTYPE]]</var> parameter: | ||
< | <p class="code">IBMV6 | ||
BPXV6 | |||
IUCVV6 | |||
</p> | |||
==Performance enhancements== | |||
===Elimination of BTB buffers=== | |||
As of version 7.7, any use of above-the-bar buffer pool (as invoked by a setting of the <var>[[NUMBUFG parameter|NUMBUFG]]</var> parameter greater than 0) will force all buffer pool buffers above the bar — no below-the-bar buffers will exist. In this case, the <var>[[NUMBUF parameter|NUMBUF]]</var> and <var>[[MINBUF parameter|MINBUF]]</var> parameters will be forced to 0, and the other parameters that affect BTB storage (<var>MAXBUF</var>, <var>SPCORE</var>, <var>LDKBMWND</var>, and <var>NLRUQ</var>) will be ignored. | |||
If you set <var>NUMBUFG</var> to 0, all buffers will be below the bar, and the settings of the BTB-related parameters will be respected and calculated as in pre-7.7 versions. | |||
===Increase in request limit for number of images, screens, and menus=== | ===Increase in request limit for number of images, screens, and menus=== | ||
Line 88: | Line 571: | ||
</ul> | </ul> | ||
== | ===Large checkpoint data sets=== | ||
Support is added for large data sets (as many as 16 million tracks) for the Model 204 Checkpoint facility [[Checkpoints: Storing before-images of changed pages#Creating the CHKPOINT.2FCHKPNT .28and CHKPNTS.29 data set|CHKPOINT or CHKPNTS data sets]]. For details, see [[System_and_media_recovery#ROLL_BACK_processing.2C_Pass_2|ROLL BACK processing, Pass 2]]. | |||
==Statistics enhancements== | |||
===BLKO=== | |||
The [[Using system statistics#System performance statistics|performance statistic]] BLKO now also reports invisible users that are blocked out. In previous releases, invisible users were not reported and BLKO remained virtually zero. The new BLKO value is more precise, and by summing BLKO, WTSV, BLKI, REDY, SWPG, and RUNG, you can now approximate USRS (average active users). | |||
For the <var>MONITOR</var> command, the [[ONLINE monitoring#User information in formatted displays|QUE column]] now reports new values OFFO and OFFI instead of OFFQ for invisible users: | |||
<ul> | <ul> | ||
<li> | <li>OFFO is invisible and blocked out. </li> | ||
< | <li>OFFI is invisible and blocked in. </li> | ||
<p> | </ul> | ||
<p> | |||
The BLKO QUE value continues to mean blocked out and visible (on some queue), and BLKI means blocked in and visible.</p> | |||
===CCATDIFF and CCATDIFH=== | |||
The [[Using system statistics#Description of statistics|CCATDIFF]] user and since-last statistic gets incremented each time a user allocates a CCATEMP page, and it gets decremented each time a user frees a page. Its value is not allowed to drop below zero. In the event of a CCATEMP page shortage, CCATDIFF gives system managers the possibility of determining a particular user that might be primarily responsible. | |||
< | <p class="note"><b>Note:</b> CCATDIFF is a rough guide, not definitive: it might give false high readings for some users, but it will indicate a user whose usage is extremely extraordinary. </p> | ||
[[Using system statistics#Description of statistics|CCATDIFH]] is a since-last statistic that reports a request's CCATDIFF since-last highwater mark, useful to retrospectively determine which request was responsible for a massive CCATEMP usage spike. For example, it will record a request that allocated a large number of CCATEMP pages but freed the pages before the request ended. | |||
==Other enhancements== | |||
===MODEL 6 screen size and back-paging=== | |||
As of Model 204 version 7.7 (and 7.5 or 7.6 with maintenance applied), a large <var>[[LOUTPB parameter|LOUTPB]]</var> value for [[Terminal MODEL 6 support|MODEL 6]] geometries is allowed, even if screen back-paging has been enabled. | |||
In previous releases, during initialization, if back-paging was enabled for the IODEV, <var>LOUTPB</var> was automatically reset to the limit that supported back-paging. | |||
Back-paging will now be disabled for any terminal with a <code>MODEL 6</code> screen geometry that requires more than 6142 bytes. | |||
===ECF calls to the IBM IDCAMS utility=== | |||
The new <var>IDCAMS</var> option for the <var>[[External Call Facility#module|External Module]]</var> statement of the Model 204 [[External Call Facility]] lets a SOUL program invoke IDCAMS without using the SYSIN and SYSPRINT DD statements. Instead, the Model 204 Universal Buffer is used to pass the input lines and receive the output lines from IDCAMS. | |||
===<b id="ecfprofile"></b>Running ECF requests under the invoking user’s profile=== | |||
<!-- see PDS-6158 -->Unless the new system parameter <var>[[ECPRIV parameter|ECPRIV]]</var> 4 bit is set, the job invoked by a privileged [[External Call Facility]] statement at a site where an external authorizer (ACF2, RACF, or Top/Secret) is used runs under the external-authorizer profile of the <i>user</i> that invokes the External Call, rather than under the <i>job's</i> external-authorizer profile. | |||
Prior to version 7.7, such a job always ran under the job's external-authorizer profile, so this is a [[#Profile used for running ECF requests|backward compatibility]] issue. | |||
==Debugger updates== | |||
===SoftSpy authorization=== | |||
<p> | |||
SoftSpy and Muse are now authorized using the standard zap AUTH mechanism.</p> | |||
<p> | |||
EDIT CONFIG is no longer used to enter authorization keys, and the second (key entry) screen of SPY EDIT CONFIG no longer appears.</p> | |||
===SoftSpy Error message for DBCSENV=== | |||
<p> | <p> | ||
As in previous releases, SoftSpy is not supported in a DBCS (double-byte character set) environment. As of version 7.7, if the CCAIN parameter DBCSENV is set to a non-zero value, the SPY command is rejected with the following message:</p> | As in previous releases, SoftSpy is not supported in a DBCS (double-byte character set) environment. As of version 7.7, if the CCAIN parameter DBCSENV is set to a non-zero value, the SPY command is rejected with the following message:</p> | ||
<p class="code">Message 207: SoftSpy may not be used in a DBCS environment.</p></ | <p class="code">Message 207: SoftSpy may not be used in a DBCS environment.</p> | ||
</ | |||
===Debugger Client version information display on mainframe=== | |||
As of version 7.7 and Client build 64, the <var class="product">Janus/TN3270 Debugger</var> Client sends its build and tag number to the mainframe, and this information is displayed in message [[MSIR.1077]]: | |||
<p class="code" style="font-size:93%">MSIR.1077: Begin debug session, user 3, client: Build: 64, Tag: 2 (Janus debugger session)</p> | |||
This information is not sent if the Debugger Client build number is less than 64, and the mainframe side views all Client versions prior to build 64 as build 63. | |||
The build number, which identifies Client versions, is displayed in the Client <b>Audit Trail</b> tab at start up: | |||
<p class="code">2016 07 30 17:21:47 The Rocket Software Debugger Client | |||
2016 07 30 17:21:47 Build: 65 (01 August 2016) Tag: 1 GA | |||
</p> | |||
You can also view the build number of the Client at any time by selecting <b>Help > About</b>. And as of Client build 65, the build number is displayed by the Client function <var>&&buildNumber()</var>. | |||
===Enforcing use of a minimum version of the Debugger Client=== | |||
Normally, when you use the TN3270 or Janus Debugger, no restrictions are placed on which version of the Debugger workstation client is used. | |||
As of Client build 65 and Model 204 7.7, you can force Clients to have at least a minimum build number in order to invoke a debugging session with your Online. The new Model 204 system parameter <var>[[MINDEBCL parameter|MINDEBCL]]</var> sets such a minimum. | |||
If you set <var>MINDEBCL</var> to a positive value, use a version of the Debugger Client whose build number is less than <var>MINDEBCL</var>, and invoke a debugging session, the debugging session is rejected. An error message is shown in your browser and at the Client, calling for a Client upgrade. | |||
You also see the following error on the Online's Audit Trail (and on the terminal if you are using <code>TN3270 DEBUG ON</code>): | |||
<p class="code" style="font-size:94%">MSIR.1079: Debugger Client Build: ''xx'' < MINDEBCL: ''yy'' debugger client connection refused | |||
</p> | |||
==Compatibility issues== | ==Compatibility issues== | ||
===APSYPAGE parameter cannot be non-zero=== | ===APSYPAGE parameter cannot be non-zero=== | ||
<p>( | <p>(Applies to the IBM z/OS system.)</p> | ||
The <var>APSYPAGE</var> parameter was disabled (but still allowed) in version 7.6. As of version 7.7, if <var>APSYPAGE</var> is non-zero, the Online will not come up and the following error message will appear: | The <var>APSYPAGE</var> parameter was disabled (but still allowed) in version 7.6. As of version 7.7, if <var>APSYPAGE</var> is non-zero, the Online will not come up and the following error message will appear: | ||
Line 110: | Line 658: | ||
See [[APSYPAGE parameter]] for information about alternatives to <var>APSYPAGE</var>. | See [[APSYPAGE parameter]] for information about alternatives to <var>APSYPAGE</var>. | ||
=== | ===Unlabeled FDV statement compilation errors=== | ||
Version 7.7 | Version 7.7 introduces an edge case incompatibility by disallowing code which is very questionable or clearly wrong; that is, previously the compiler allowed pretty much any statements between the label and the FDV. Such statements are no longer allowed. | ||
For example, the following was allowed in older versions of Model 204: | For example, the following was allowed in older versions of Model 204: | ||
<p class="code"> | <p class="code">a: audit 'About to FDV' | ||
fdv foo | |||
b: frv in a</p> | |||
Inserting SOUL code between a label and an FDV statement is no longer allowed, and so the result of the above is: | Inserting SOUL code between a label and an FDV statement is no longer allowed, and so the result of the above is: | ||
Line 122: | Line 670: | ||
<p class="code">M204.0311 Unacceptable statement reference</p> | <p class="code">M204.0311 Unacceptable statement reference</p> | ||
This change | This change is propagated by zap maintenance to versions 7.6 and 7.5 of Model 204. | ||
===KOMM addressing changes=== | ===KOMM addressing changes=== | ||
Line 135: | Line 683: | ||
For context, see [[Customizing functions and translation tables#Converting user-written functions|Converting user-written functions]]. | For context, see [[Customizing functions and translation tables#Converting user-written functions|Converting user-written functions]]. | ||
===JANUS WEB ON -- "M substitution=== | |||
In the command for a <var>JANUS WEB ON</var> rule, <code>"M</code> can now be used to specify a method name. | |||
This behavior is a change from past releases, when <code>"M</code> was simply converted to <code>M</code>. See [[#ON rules .28method name substitution.29|JANUS WEB ON rules (method name substitution)]] for details. | |||
===Journal format compatibility=== | |||
A recovery code error unintentionally allowed recovery to be run using Model 204 7.6 against a version 7.5 journal, and vice versa. Although the error was benign because the journal formats were the same in those versions, mixing of journal versions and Model 204 versions is no longer allowed. | |||
===Profile used for running ECF requests=== | |||
As [[#ecfprofile|described earlier]], the default external-authorizer (ACF2, RACF, or Top/Secret) profile under which a job invoked by a privileged ECF statement runs is changed in version 7.7. Instead of such a job running under the job's external-authorizer profile (as it did prior to 7.7), the job runs by default in 7.7 under the user's external-authorizer profile. | |||
The default behavior can be changed by turning on the new system parameter <var>[[ECPRIV parameter|ECPRIV]]</var> 4 bit. | |||
===$ListNew cannot be used in Initial clause=== | |||
<var>$ListNew</var> cannot be used in the <var>Initial</var> clause of a [[Using_variables_and_values_in_computation#Declare_statements_for_.25variables|declaration statement]]. | |||
<p>This change was introduced as zap maintenance in versions 7.5, 7.6, and 7.7 of Model 204.</p> | |||
==Notes for system manager and installer== | |||
===CRAM SVC installation is deprecated=== | |||
The CRAM SVC installation has been deprecated as of version 7.5. <br />Installation of CRAM-XDM is described as part of the [[Model 204 installation]]. | |||
===Authorization and maintenance zaps=== | |||
When you download Rocket M204 product object files, all relevant authorization keys and all current maintenance zaps are pre-applied to the object files as part of the download process. | |||
==New and updated messages== | ==New and updated messages== | ||
See [[New and updated messages in Model 204 version 7.7 | See [[New and updated messages in Model 204 version 7.7|New and updated messages in Model 204 version 7.7]] for details. | ||
[[Category: Release notes]] | [[Category: Release notes|Model 204 version 7.7]] |
Latest revision as of 19:38, 18 September 2024
These release notes list the enhancements and other changes contained in Model 204 version 7.7.
Overview
These release notes contain installation and features information for the Rocket Model 204 version 7.7 release. Before beginning your installation, please read through this information about product installation and changes.
New in this release
The table below cites some highlights of Model 204 version 7.7. For a full list of features, refer to the Table of Contents.
Category | Feature |
---|---|
Performance |
|
Security |
|
Add-on enhancements |
|
Operating system and hardware requirements
Operating system requirements
- IBM z/OS versions supported:
- All IBM supported releases up to and including z/OS 3.1.
(For z/OS 2.2, see IBM z/OS 2.2 PTF requirement.) - zHPF support requires version 2.1.
- Large (1 MB) page support requires version 1.9.
- Extended address volumes (EAV) requires version 1.12.
Version 1.07 is sufficient for all functionality except for the following features:
On z/OS, Model 204 release 7.7 operates as an APF authorized load module, as required by many 7.7 features.
To run Model 204 unauthorized, contact Technical Support. - All IBM supported releases up to and including z/OS 3.1.
- IBM z/VM versions supported:
- All IBM supported releases up to and including z/VM 7.3.
- IBM z/VSE versions supported:
- All IBM supported releases up to and including z/VSE 6.1.
Hardware requirements
In general, Model 204 version 7.7 requires the IBM z/890 or above processor.
However, the IBM z10 or above processor is required for the following features:
- large (1 MB) page support
- IBM's High Performance FICON (zHPF) support
Model 204 compatibility with operating systems
For information on Model 204 certification with IBM operating systems, see Model 204 system requirements.
Connect★ compatibility with Model 204
Connect★ version 7.5 or 7.7 is compatible with Model 204 version 7.7.
For more information on Connect★ installation, see the Connect★ wiki pages.
SOUL (User Language) enhancements
New and changed classes and methods
New exception class: WriteError
WriteError exceptions are thrown by the Close, WriteBlock, WriteRecord, and WriteRecords methods in the Dataset class if they encounter a full output Dataset object.
New default certificate-signing algorithm
Janus Network Security as well as the StringList methods AppendSignedCertificate and AppendSignedClientCertificate methods have changed their default signature algorithm from SHA-1 to SHA-256.
This change is propagated by zap maintenance to versions 7.6 and 7.5 of Model 204.
"SSL" String methods
These new methods are added:
Method | Description |
---|---|
SHA384digest | SHA-384 digest |
SHA512digest | SHA-512 digest |
New LoadMsgctl method
The new LoadMsgctl method lets you view what Model 204 messages have been affected by MSGCTL commands. The method also displays the current attributes of those messages.
In addition, to better understand the effect of the MSGCTL command, the RKTools SIRIUS
file will contain a procedure you can use to display the MSGCTL commands that have been specified in the Online session.
New DigestAlgorithm values
Values SHA384 and SHA512 are added to the DigestAlgorithm enumeration.
Method variable invocation
Method variables can now be invoked using %var()
or %obj:var()
, as in JavaScript.
X509CertificateToXmlDoc method support for unknown elements
A certificate's <RelativeDistinguishedName>
element can contain a wide variety of attributes that X509CertificateToXmlDoc does not understand. Under Model 204 7.6 and earlier, this results in a parse exception, but under 7.7 and later, such attributes are added as <unknown>
elements with an <ObjectIdentifier>
element that indicates the ASN.1 object identifier.
Note: You are advised not to refer to such an <unknown>
element in your programs, since future updates to the X509CertificateToXmlDoc method might add support for the element, in which case the element name will change to a proper name. If such an element is of interest, contact Rocket Software technical support.
Resulting element length in "ToXmlDoc" String methods
Prior to version 7.7 of Model 204, the DerToXmlDoc, X509CertificateToXmlDoc, X509CrlToXmlDoc, and RSAPrivateKeyToXmlDoc methods failed if input to them created any element in the result XmlDoc with a text child whose length exceeded 650 characters. An example of such input is a 4096-bit key (which requires 1024 hex characters).
As of version 7.7, the lengths of the created text nodes are not restricted.
LDAP request length limit
Prior to version 7.7 of Model 204, the SOUL LDAP client buffers allowed a limit of 6144 bytes per request. As of 7.7, the limit is increased to 8184.
New XHTML entities for square-bracket characters
[ and ] are newly supported as XMHTL entities (notably in the U method). This provides a better approach to specifying square brackets (such as for XPath expressions) than the formerly recommended use of Static %variables initialized to the correct values.
This change is propagated by zap maintenance to version 7.6 of Model 204.
For example, to produce an XPath expression equivalent to the following:
*/pers[@name="Hector"]
Code like this was recommended under version 7.5 of Model 204:
%lsq is string len 1 static initial('['):u %rsq is string len 1 static initial(']'):u . . . %myXmldoc:print('*/pers' %lsq '@name="Hector"' %rsq)
Under version 7.6 and above, you can instead use the new entities and avoid the declarations, concatenations, and runtime conversions required above:
%myXmldoc:print('*/pers[@name="Hector"]':u)
Procedure names can begin with zero
Formerly, a procedure name was not allowed to begin with a zero or a minus sign. As of version 7.7, a procedure name can begin with a zero, and alphanumeric procedure names can begin with a minus sign (-), which is interpreted as a hyphen. For example, 00123
, -1myproc
, and -myproc
are valid procedure names.
See the PROCEDURE command for details.
Assert statement support for Info expressions
The SOUL Assert statement allows the optional parameter Info to provide additional output information. As of version 7.7, the Info phrase may contain any valid SOUL expression, including a method call or $function. The expression, which must be enclosed in parentheses, is evaluated only in the case of an Assert failure.
A simple example is:
assert %x gt 0, info ('abc' with 'def')
Note: This enhancement introduces a slight backward incompatibility: An Assert statement like the following, whose Info value begins with an opening parenthesis but has no closing parenthesis, compiled without error prior to version 7.7:
assert %x gt 0, info (
From 7.7 on, such a statement produces a compilation error, because the compiler expects an expression after the open parenthesis.
Security enhancements
Long password support
Logon passwords, maintained in CCASTAT, can now contain as many as 127 characters.
Also, passwords and passphrases can now contain one or more embedded spaces. (Leading and trailing spaces are stripped.)
The long password feature includes support for:
- LOGON command
- LOGONCP command, used to change a password
- LOGCTL C USERID command
- $Sir_Login function
- Mixed-case passwords (if the CUSTOM parameter includes the value 11)
- CCASTAT data sets created with or without password expiration support
- Long passwords (passphrases) for use with the following external security interfaces: CA-ACF2 MVS, Security Server (formerly RACF), and CA-Top Secret
Note: This feature is available for logon passwords only; it does not apply to file passwords.
No changes to CCASTAT and no new CCAIN parameters are required to enable long password support.
In order to allow embedded blanks in passwords passed on IFSTRTN calls, a semicolon is required as the password delimiter and the CUSTOM parameter 24 value must be set.
For additional security enhancements in version 7.7, see Janus Network Security ciphers and private keys as well as "SSL" String methods, New DigestAlgorithm values, and New default certificate-signing algorithm.
Janus product enhancements
Support for IPV6
As of version 7.7, customers can use the Janus products in an IPV6 (Internet Protocol Version 6) environment. Before this release, all Janus commands and parameters were able to accommodate IPV4 addresses only. IPV6 addresses expand the network address space from 32 to 128 bits.
These parameters, commands, and functions support IPV6 under version 7.7 of Model 204:
Commands | System parameter | SOUL |
---|---|---|
JANUS CLSOCK and JANUS SRVSOCK |
TCPTYPE |
$Web_IPAddr |
Janus Network Security ciphers and private keys
Support for certificates signed using SHA-384 and SHA-512 are added to Janus Network Security. This makes it possible to generate certificates signed with these algorithms and to accept server or client certificates signed with these algorithms.
In addition, support is added for RSA keys that are as many as 4096 bits in length. You can now generate and sign 4096-bit keys and use them in client and server certificates using Janus Network Security application as well as its associated and related methods, including:
Janus Web Server rules
The following changes have been made in version 7.7:
- Janus Web used to automatically implement two web server ON rules to set up access to the Janus Web sample home page and to demonstration application procedures. These rules were removed in version 7.6 (by zap maintenance) and are not present in version 7.7.
- You can now substitute an HTTP method name in the command for a JANUS WEB ON rule. See ON rules (method name substitution) for details.
- The automatic JANUS WEB ALLOW rule, which allowed any user to access the port without requiring a login, is changed for non-SSL ports to the following:
JANUS WEB portname DISALLOW *
This rule requires a system administrator to explicitly define ALLOW rules to enable users to access non-SSL ports. The rule applies (after zap 77Z088 in version 7.7, or after zap 76Z418 in version 7.6) unless overridden by user-added rules.
Note: With version 7.7 zap 77Z090 or version 7.6 zap 76Z420, you can make the default ALLOW rule as it was in version 7.5 and earlier (
ALLOW *
). To do so, turn on the 1 bit of the WEBDFLT parameter:RESET WEBDFLT=1
- As described below in JANUS WEB (additional rule support), the JANUS WEB command ALLOW and DISALLOW rules are updated to include support for RESTful and WebDAV HTTP methods.
Janus Web access to HTTP authorization and authentication headers
Under version 7.7, Janus Web lets you access HTTP user authentication headers. You can capture the HTTP "Authorization" request header value, and you can set the "WWW-Authenticate" response header. See Authorization and WWW-Authenticate headers.
Fast/Unload enhancements
Integration of Fast/Unload with the Online load module
Previously (for all versions of Fast/Unload through 4.7), the standalone FUNLOAD
load module was downloaded and linked separately and independently from Model 204. Starting with version 7.7 of Model 204:
- Fast/Unload is entirely linked with the Model 204 Online load module.
- Maintenance zaps applied to the Online load module include all Fast/Unload maintenance.
- The version number of Fast/Unload is the same as the version number of Model 204.
- If you are authorized for Fast/Unload, the authorization zap for the ONLINE load module will contain authorization for Fast/Unload. The authorization zap used for previous releases of FUNLOAD should not be applied to the FUNLOAD module in 7.7.
Under 7.7, the Online load module can be linked with an ALIAS (the standard one is FUNLOAD) and an alternate ENTRY. This alias is functionally indistinguishable from the standalone Fast/Unload FUNLOAD load module installed for all previous versions of Fast/Unload.
The integration of Fast/Unload with the Online load module also makes additional DDnames available to PGM=FUNLOAD for possible problem diagnosis by Rocket Technical Support. These DDnames are CCASNAP
, CCAAUDIT
, and CCAPRINT
, and they are described in Fast/Unload invocation.
A significant benefit of running Fast/Unload integrated with Model 204 and not standalone is the ability to take advantage of zIIP processing, as described next in the "zIIP exploitation" section.
zIIP exploitation
If you have an authorization zap that contains both of the following, your standalone PGM=FUNLOAD jobs will run on a zIIP processor, if one is available:
- M204 HPO, the zIIP-support product of Model 204
PGM=FUNLOAD automatically supplies the necessary Model 204 parameters to enable zIIP exploitation.
- The Fast/Unload HPO product
New #VIEW204 function
The #VIEW204 function returns the value of the Model 204 parameter you specify as an argument.
PUT statement enhancements
Length prefix for PUT output values
New PUT statement syntax is added to insert a one-byte or two-byte binary integer, containing the byte length of a PUT value, in the output stream before the value.
For better readability and lower CPU cost than the techniques currently used to achieve the same result, the AS clause of a PUT statement will now allow the COUNTED keyword:
... PUT info .. AS [format] COUNTED[1|2]
For example, PUT FIRST.NAME AS COUNTED2
puts the first occurrence of field FIRST.NAME
as a string value, preceded by a two-byte binary integer containing the length of that occurrence.
With this feature, you can replace FUEL code such as the following:
%VAL = ITEM.CODE(%OCC) %LEN = #LEN( %VAL ) PUT %LEN AS FIXED(2) PUT %VAL
With:
PUT %VAL AS COUNTED2
#function as PUT "info" argument
New in this version, a #function call is allowed as the PUT info argument. For example, instead of FUEL code such as the following:
%VAL = #STRIP(ITEM.VALUE(%OCC), 'L', 0) PUT %VAL
You can use this more readable and somewhat more efficient equivalent:
PUT #STRIP(ITEM.VALUE(%OCC), 'L', 0)
#STRIP function enhancements
New #STRIP fourth argument
The new fourth argument of #STRIP lets you designate a #STRIP first-argument value to be nullified. That is, when the value of the first argument is equal to the value of the fourth argument, #STRIP returns a null string. You might use this optional argument for fields that have a "placeholder value" or "default value" which is not actual data.
This argument can be conveniently combined with the new COUNTED options for PUT, because a length-prefixed format allows a reliable, unambiguous representation of a series of null strings.
Combining the new fourth argument, the new COUNTED2 option, and the new N option of the second argument provides a simpler alternative to FUEL code such as the following:
%VAL = ITEM.STRING(%OCC) IF %VAL EQ '_' THEN PUT 0 AS FIXED(2) ELSE %LEN = #LEN(%VAL) PUT %LEN AS FIXED(2) PUT %VAL END IF
You can replace the above statements by the more readable and efficient:
PUT #STRIP(ITEM.STRING(%OCC), 'N', , '_') AS COUNTED2
New #STRIP type options
P and N strip-type options are added to the #STRIP function:
- The new P option strips all but one leading pad-argument characters from the #STRIP first argument returned value, if that value contains a non-zero length string of only pad characters.
P, together with other new Fast/Unload PUT features, provides a simpler alternative to FUEL code such as the following:
%VAL = ITEM.NUMBER(%OCC) IF %VAL EQ '_' OR %VAL EQ '' THEN PUT 0 AS FIXED(2) ELSE %VAL = #STRIP(%VAL, 'L', '0') IF %VAL EQ '' THEN %VAL = '0' END IF %LEN = #LEN(%VAL) PUT %LEN AS FIXED(2) PUT %VAL END IF
You can replace the above statements with the following, which outputs a numeric value with leading zeroes stripped:
PUT #STRIP(ITEM.NUMBER(%OCC), 'P', '0', '_') AS COUNTED2
Note: A FUEL IF statement oddity is that the precedence of AND and OR are the same.
- The new N option strips neither leading-characters nor trailing-characters.
For an example, see New #STRIP fourth argument, above.
New and changed commands
AUTHCTL VIEW (additional information displayed)
The AUTHCTL command output now includes a list of the available sets of control parameters for the external security interface you specify in the command.
DISPLAY MODMAP (new parameter: UEX)
The DISPLAY MODMAP command now has a UEX parameter that displays the entry point addresses of all defined user exits.
FREE command (new message)
Prior to this release, a successful FREE command was not followed by a message indicating success. Under version 7.7, FREE now indicates success with the following message:
M204.0510: FREE command successful; ddname freed
Also new in this release, a FREE command that takes no action because the specified file does not exist or is not allocated is now followed by an explanatory message:
M204.0509: No action taken by FREE command; ddname not allocated
In earlier versions, no such message followed.
JANUS DEFINE (new parameter: SSLTRUST)
The JANUS DEFINE command now has an SSLTRUST parameter that indicates that the certificate presented by the other side of a TLS/SSL connection is to be accepted even if it is not signed by a known certifying authority.
JANUS WEB (additional rule support)
Expanded ALLOW/DISALLOW rules
The JANUS WEB command ALLOW/DISALLOW rules are updated to include support for these HTTP methods:
- The RESTful (Representational State Transfer) methods CONNECT, DELETE, OPTIONS, PATCH, and TRACE.
- The WebDAV (Distributed Authoring and Versioning) methods PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK.
ON rules (method name substitution)
In a version 7.7 JANUS WEB ON command, you can now reference the name of the HTTP method that is associated with the incoming request. To do this, specify an M
after the escape (") character, as in:
JANUS WEB WEBPORT ON /TEST/* OPEN FILE TEST CMD 'I "M.*'
A GET request for URL /test/foo
would result in the file TEST
being opened and the command I GET.FOO
being issued. A POST for the same URL would result in the command I POST.FOO
being issued.
Note: This behavior is a change from past releases, when "M
was simply converted to M
.
LOGINCP or LOGONCP (new)
Because colons are now valid password characters, the LOGINCP (LOGIN and Change Password) command replaces the former technique for changing passwords using LOGIN.
Before version 7.7, with LOGIN, you specified oldpassword:newpassword in response to the M204.0347: Password
prompt.
With the LOGINCP command, you are prompted and re-prompted for the new password after successful logon:
LOGINCP USER1 M204.0347: Password M204.0353: USER1 USER1 login 16 JUL 29 12.38 M204.2633: Enter new password M204.2633: Re-enter new password M204.0350: New password accepted M204.0345: CCASTAT updated
LOGONCP is a synonym for LOGINCP.
ZHPF (new parameters: filename and *)
The ZHPF command checks zHPF ability for the file currently opened by the user.
As of Model 204 7.7, you can specify parameters to ZHPF:
- filename, to check a specific file
- An asterisk (*), to check local files opened by all users
New and changed parameters
CUSTOM (new and changed values)
New values
The following values have been added to the CUSTOM parameter in this release:
- The
CUSTOM=23
value always truncates the user ID to 10 characters. - The
CUSTOM=41
value allows recording of data on successful RACF user logins. The login data is shown in RACFRW batch reports. - The
CUSTOM=42
value allows the editing of procedure names containing the following special characters: comma, equal sign, space, single quote, semicolon.
Changed value
- The
CUSTOM=11
value also supports special-characters for RACF passwords as of version 7.7.
LFSCB (new default/minimum value)
The default (and minimum) value of LFSCB is now 8 bytes.
LITBL (new default/minimum value)
The default (and minimum) value of LITBL is now 8 bytes.
MINDEBCL (new)
The new system parameter, MINDEBCL, can be set in an Online to specify the minimum Debugger Client build number that can be used with that Online.
MPDELAY and MPDELAYZ (new)
For an MP/204 Online, the MPDELAY and MPDELAYZ parameters are added to improve the efficiency of the MP scheduler. They reduce the cost of starting too many new subtasks for the amount of work to be done.
NUMBUF and NUMBUFG
As described below in Elimination of BTB buffers, setting NUMBUFG greater than 0 in version 7.7 forces NUMBUF to 0 (no buffer pool buffers reside below the bar). Not setting NUMBUFG or setting it to 0 (no buffers above the bar) allows the calculation of BTB buffers to remain as in previous versions.
SCHDOFL and SCHDOFLZ (new minimum value)
The new minimum value of SCHDOFL and SCHDOFLZ is 0. Before Model 204 7.7, their minimum allowed value was 1.
SCHDOFLS (new)
For z/OS system customers using Model 204 zIIP support, the new SCHDOFLS system parameter helps you to regulate the zIIP processor workload.
SCHDOFLS specifies both of the following:
- The target number of threads on the zIIP offload queue before a non-SRB MP subtask is dispatched to help the zIIP subtasks.
- If started, how aggressively non-SRB MP subtasks pick up work from the zIIP offload queue.
This parameter applies to z/OS only.
SCHDOPT (change to X'20' bit processing)
The SCHDOPT X'20' bit prevents the maintask from running work that is intended to run on a zIIP subtask (when zIIP subtasks are defined and activated). As of Model 204 7.7, even when this bit is off, the maintask will run some of the zIIP work only if the zIIP subtasks appear to be saturated. Saturation is defined as a zIIP subtask queue length of at least SCHDOFLZ*AMPSUBZ
.
Formerly, this saturation requirement was absent, allowing the maintask to take on more (possibly too much) of the zIIP workload.
SERVSIZE (new default/minimum value)
The minimum value for SERVSIZE is changed from zero to 65536. If SERVSIZE is explicitly set in CCAIN and its value is less than 64K, the following message is issued:
M204.1149: SERVSIZE has been set to its minimum value: 65536
If SERVSIZE was not set but was calculated by the system to a value less than 64K, the following message is issued:
M204.0163: SERVSIZE increased to 65536
This change is propagated by zap maintenance to versions 7.6, 7.5, and 7.4 of Model 204.
TCPTYPE (new IPV6 values)
As part of the version 7.7 support for IPV6, three new optional (IPV6-address-only) values are added to the TCPTYPE parameter:
IBMV6 BPXV6 IUCVV6
Performance enhancements
Elimination of BTB buffers
As of version 7.7, any use of above-the-bar buffer pool (as invoked by a setting of the NUMBUFG parameter greater than 0) will force all buffer pool buffers above the bar — no below-the-bar buffers will exist. In this case, the NUMBUF and MINBUF parameters will be forced to 0, and the other parameters that affect BTB storage (MAXBUF, SPCORE, LDKBMWND, and NLRUQ) will be ignored.
If you set NUMBUFG to 0, all buffers will be below the bar, and the settings of the BTB-related parameters will be respected and calculated as in pre-7.7 versions.
These limits are increased to 4095 per request:
- The total number of images for all blocks (formerly 256)
- The maximum number of menus and screens combined (formerly 256)
Large checkpoint data sets
Support is added for large data sets (as many as 16 million tracks) for the Model 204 Checkpoint facility CHKPOINT or CHKPNTS data sets. For details, see ROLL BACK processing, Pass 2.
Statistics enhancements
BLKO
The performance statistic BLKO now also reports invisible users that are blocked out. In previous releases, invisible users were not reported and BLKO remained virtually zero. The new BLKO value is more precise, and by summing BLKO, WTSV, BLKI, REDY, SWPG, and RUNG, you can now approximate USRS (average active users).
For the MONITOR command, the QUE column now reports new values OFFO and OFFI instead of OFFQ for invisible users:
- OFFO is invisible and blocked out.
- OFFI is invisible and blocked in.
The BLKO QUE value continues to mean blocked out and visible (on some queue), and BLKI means blocked in and visible.
CCATDIFF and CCATDIFH
The CCATDIFF user and since-last statistic gets incremented each time a user allocates a CCATEMP page, and it gets decremented each time a user frees a page. Its value is not allowed to drop below zero. In the event of a CCATEMP page shortage, CCATDIFF gives system managers the possibility of determining a particular user that might be primarily responsible.
Note: CCATDIFF is a rough guide, not definitive: it might give false high readings for some users, but it will indicate a user whose usage is extremely extraordinary.
CCATDIFH is a since-last statistic that reports a request's CCATDIFF since-last highwater mark, useful to retrospectively determine which request was responsible for a massive CCATEMP usage spike. For example, it will record a request that allocated a large number of CCATEMP pages but freed the pages before the request ended.
Other enhancements
MODEL 6 screen size and back-paging
As of Model 204 version 7.7 (and 7.5 or 7.6 with maintenance applied), a large LOUTPB value for MODEL 6 geometries is allowed, even if screen back-paging has been enabled.
In previous releases, during initialization, if back-paging was enabled for the IODEV, LOUTPB was automatically reset to the limit that supported back-paging.
Back-paging will now be disabled for any terminal with a MODEL 6
screen geometry that requires more than 6142 bytes.
ECF calls to the IBM IDCAMS utility
The new IDCAMS option for the External Module statement of the Model 204 External Call Facility lets a SOUL program invoke IDCAMS without using the SYSIN and SYSPRINT DD statements. Instead, the Model 204 Universal Buffer is used to pass the input lines and receive the output lines from IDCAMS.
Running ECF requests under the invoking user’s profile
Unless the new system parameter ECPRIV 4 bit is set, the job invoked by a privileged External Call Facility statement at a site where an external authorizer (ACF2, RACF, or Top/Secret) is used runs under the external-authorizer profile of the user that invokes the External Call, rather than under the job's external-authorizer profile.
Prior to version 7.7, such a job always ran under the job's external-authorizer profile, so this is a backward compatibility issue.
Debugger updates
SoftSpy authorization
SoftSpy and Muse are now authorized using the standard zap AUTH mechanism.
EDIT CONFIG is no longer used to enter authorization keys, and the second (key entry) screen of SPY EDIT CONFIG no longer appears.
SoftSpy Error message for DBCSENV
As in previous releases, SoftSpy is not supported in a DBCS (double-byte character set) environment. As of version 7.7, if the CCAIN parameter DBCSENV is set to a non-zero value, the SPY command is rejected with the following message:
Message 207: SoftSpy may not be used in a DBCS environment.
Debugger Client version information display on mainframe
As of version 7.7 and Client build 64, the Janus/TN3270 Debugger Client sends its build and tag number to the mainframe, and this information is displayed in message MSIR.1077:
MSIR.1077: Begin debug session, user 3, client: Build: 64, Tag: 2 (Janus debugger session)
This information is not sent if the Debugger Client build number is less than 64, and the mainframe side views all Client versions prior to build 64 as build 63.
The build number, which identifies Client versions, is displayed in the Client Audit Trail tab at start up:
2016 07 30 17:21:47 The Rocket Software Debugger Client 2016 07 30 17:21:47 Build: 65 (01 August 2016) Tag: 1 GA
You can also view the build number of the Client at any time by selecting Help > About. And as of Client build 65, the build number is displayed by the Client function &&buildNumber().
Enforcing use of a minimum version of the Debugger Client
Normally, when you use the TN3270 or Janus Debugger, no restrictions are placed on which version of the Debugger workstation client is used. As of Client build 65 and Model 204 7.7, you can force Clients to have at least a minimum build number in order to invoke a debugging session with your Online. The new Model 204 system parameter MINDEBCL sets such a minimum.
If you set MINDEBCL to a positive value, use a version of the Debugger Client whose build number is less than MINDEBCL, and invoke a debugging session, the debugging session is rejected. An error message is shown in your browser and at the Client, calling for a Client upgrade.
You also see the following error on the Online's Audit Trail (and on the terminal if you are using TN3270 DEBUG ON
):
MSIR.1079: Debugger Client Build: xx < MINDEBCL: yy debugger client connection refused
Compatibility issues
APSYPAGE parameter cannot be non-zero
(Applies to the IBM z/OS system.)
The APSYPAGE parameter was disabled (but still allowed) in version 7.6. As of version 7.7, if APSYPAGE is non-zero, the Online will not come up and the following error message will appear:
M204.2958: APSYPAGE is obsolete as of 7.6. Rocket recommends using RESPAGE and/or TEMPPAGE as the alternative
See APSYPAGE parameter for information about alternatives to APSYPAGE.
Unlabeled FDV statement compilation errors
Version 7.7 introduces an edge case incompatibility by disallowing code which is very questionable or clearly wrong; that is, previously the compiler allowed pretty much any statements between the label and the FDV. Such statements are no longer allowed.
For example, the following was allowed in older versions of Model 204:
a: audit 'About to FDV' fdv foo b: frv in a
Inserting SOUL code between a label and an FDV statement is no longer allowed, and so the result of the above is:
M204.0311 Unacceptable statement reference
This change is propagated by zap maintenance to versions 7.6 and 7.5 of Model 204.
KOMM addressing changes
- KU is no longer 4K addressable from KOMM. It has been relocated to KOMM+1100 and must be addressed using grande (‘G’) instructions.
- KHEOC has been renamed to KGEOC.
- KUUSRNO has been renamed to KBUSRNO.
- In addition, all KUP… fields have been removed and replaced by their 64-bit equivalent KUG… fields.
For example, before 7.7, VTBL might be addressed by usingL R1,KUPVT
.
As of version 7.7, that reference would requireLG R1,KUGVT
.
For context, see Converting user-written functions.
JANUS WEB ON -- "M substitution
In the command for a JANUS WEB ON rule, "M
can now be used to specify a method name.
This behavior is a change from past releases, when "M
was simply converted to M
. See JANUS WEB ON rules (method name substitution) for details.
Journal format compatibility
A recovery code error unintentionally allowed recovery to be run using Model 204 7.6 against a version 7.5 journal, and vice versa. Although the error was benign because the journal formats were the same in those versions, mixing of journal versions and Model 204 versions is no longer allowed.
Profile used for running ECF requests
As described earlier, the default external-authorizer (ACF2, RACF, or Top/Secret) profile under which a job invoked by a privileged ECF statement runs is changed in version 7.7. Instead of such a job running under the job's external-authorizer profile (as it did prior to 7.7), the job runs by default in 7.7 under the user's external-authorizer profile.
The default behavior can be changed by turning on the new system parameter ECPRIV 4 bit.
$ListNew cannot be used in Initial clause
$ListNew cannot be used in the Initial clause of a declaration statement.
This change was introduced as zap maintenance in versions 7.5, 7.6, and 7.7 of Model 204.
Notes for system manager and installer
CRAM SVC installation is deprecated
The CRAM SVC installation has been deprecated as of version 7.5.
Installation of CRAM-XDM is described as part of the Model 204 installation.
Authorization and maintenance zaps
When you download Rocket M204 product object files, all relevant authorization keys and all current maintenance zaps are pre-applied to the object files as part of the download process.
New and updated messages
See New and updated messages in Model 204 version 7.7 for details.