Release notes for Model 204 version 7.7: Difference between revisions
(deleting this section since this feature is being backed out of 7.7) |
|||
| Line 302: | Line 302: | ||
<li>The version number of <var class="product">Fast/Unload</var> is the same as the version number of Model 204. </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 is automatically applied to the object at download time. The authorization zap used for previous releases of FUNLOAD should not be applied to the FUNLOAD module in 7.7.</li> | |||
</ul> | </ul> | ||
Revision as of 15:25, 28 March 2017
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 2.2.
- 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. - IBM z/VM versions supported:
- All IBM supported releases up to and including z/VM 6.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.
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 is automatically applied to the object at download time. 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
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 values)
The following values have been added to the CUSTOM parameter in this release:
- The CUSTOM=23 value always truncates the userid 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.
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.
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.
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.
New and updated messages
See New and updated messages in Model 204 version 7.7 for details.