Release notes for Model 204 version 7.8
******THIS IS A DRAFT DOCUMENT.******
These release notes list the enhancements and other changes contained in Model 204 version 7.8, which is still in development. Until the commercial release of the software, Rocket reserves the right to add to, remove, or change anything described herein.
Overview
These release notes contain installation and features information for the Rocket Model 204 version 7.8 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.8. For a full list of features, refer to the Table of Contents.
See also the Compatibility section for possible issues.
| Category | Feature |
|---|---|
| SOUL |
|
| Janus Web |
|
| Networking |
Note: The two-phase commit and commit exits features are licensed and purchased separately from Model 204.
|
| ECF tables |
|
| Performance |
|
| Security |
|
| System enhancements |
|
| AUDIT204 enhancements |
|
| New commands |
|
| New parameters |
|
| Janus and TN3270 debuggers |
|
| User/system statistics |
|
Operating system and hardware requirements
Operating system requirements
- IBM z/OS versions supported:
- All IBM supported releases up to and including z/OS 2.3.
(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.8 operates as an APF authorized load module, as required by many 7.8 features.
To run Model 204 unauthorized, contact Technical Support. - All IBM supported releases up to and including z/OS 2.3.
- IBM z/VM versions supported:
- All IBM supported releases up to and including z/VM 6.4.
- 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.8 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
Connect★ compatibility with Model 204
Connect★ version 7.5 or 7.7 is compatible with Model 204 version 7.8.
For more information on Connect★ installation, see the Connect★ wiki pages.
SOUL (User Language) enhancements
AmIndependent method
The AmIndependent method returns TRUE for daemons spawned by RunIndependently. (The action of AmDaemon remains unchanged.)
The following table shows the values returned by AmIndependent versus AmDaemon for different daemon types:
| Type | AmDaemon | AmIndependent |
|---|---|---|
| $COMBG | False | False |
| Independent daemon | False | True |
| Other daemon | True | False |
| Web, etc. | False | False |
EndsWith function
The EndsWith String function determines if one string ends with the characters in another. This is analogous to the StartsWith function except, of course, it checks the end of a string rather than the start.
The following code snippet:
printText {~="War and Peace":endsWith("Peace")} printText {~="War and Peace":endsWith("War")}
displays:
"War and Peace":endsWith("Peace")=True "War and Peace":endsWith("War")=False
$ProcOpn
$ProcOpn now supports the opening of a procedure with an all-numeric name, and including a leading zero, such as:
%result = $procOpn('0123', 'MYFILE')
Support for such procedure names was initially introduced at V7.7, and this feature of $ProcOpn is enabled in V7.7 with the application of zap 77z054.
Allow parentheses to surround a boolean enumeration object
The following sample code:
begin variables are undefined %isValid is boolean initial (True) if (%isValid) then print 'in IF' end if end
will now compile and run successfully, since this syntax:
if (%isValid) then
is logically equivalent to this:
if %isValid then
Prior to V7.8 the presence of parentheses surrounding the boolean enumeration object would have caused a compilation error. This change is enabled in V7.7 with the application of zap 77z370.
Support for copying Object class objects
The Object class now supports the copy and deepCopy methods. For example, an Object object can be copied as follows:
begin %x is object object %y is object object %y = new %x = %y:copy end
This change is enabled in v7.7 with the application of zap 77z076, and within V7.6 with the application of zap 76z412.
Assignment of enumeration values to method variables
Enumeration values can now be assigned to method variables whose result is an enumeration. So, for example, the following code:
begin enumeration colour public value red value white value blue end public end enumeration %func is function getColour is enumeration colour local function getColour is enumeration colour return blue end function %func = getColour %func = (colour):red printText {~=%(Local):(%func)} end
will produce this result:
%(Local):(%func)=red
whereas previously this line:
%func = (colour):red
would have been rejected with this message:
MSIR.0993: Assignment invalid: mismatch between method and method variable
This change is enabled in V7.7 with the application of zap 77z128.
Optional output method parameters
Prior to this release output parameters could not be optional or have default values. In this release output parameters can be specified as Optional, and a default value can be specified with Default. One related change is that if a Len value is specified with Optional or Default Output, it indicates the length of the hidden target for the output parameter if none was passed. For all other Output parameters, Len is meaningless, just as it was before Model 204 V7.8. The following is an example of the use of an optional output parameter:
function getRemote( - %target is string len 32, %errorReason is string len 80 optional output - ) is float ...
In this example, if %errorReason is not specified in a call and then set to a value longer than 80 bytes it will be truncated to 80 bytes. However, if a string of a different length is passed, the length of that string will determine truncation behavior.
External Call Facility enhancements
Managing ECF tables more efficiently
There are two new features to help manage ECF tables more efficiently, avoid conditions where the table can fill, and prevent the definition of further entities.
The first feature is the new DISPLAY ECF command, which displays the contents of ECF tables and also the current status of users accessing ECF modules. See more details of the DISPLAY ECF command below.
The second feature is a new EXTERNAL REMOVE statement with the following syntax:
EXTERNAL REMOVE modulename
This statement causes the entry for the named module to be removed from the module table. The table entry is then placed on a free chain of entries and can be reused by issuing the EXTERNAL MODULE statement. This allows the module table to be managed with redundant entries removed, without having to recycle the ONLINE.
An EXTERNAL REMOVE statement will return $status/$statusd values of 0/0, and most other status values that can be returned by the EXTERNAL REMOVE statement are already documented in the ECF return codes table. If an EXTERNAL REMOVE is attempted against a module that is currently being called (in use), then $status/$statusd will return the values 20/1 (module unavailable).
System enhancements
New wait types for daemon/master waits
Two new wait types, viewable on the MONITOR USERS command output, have been implemented as follows:
57 - Means a daemon thread waiting for its master thread
58 - Means a master thread waiting for one of its daemon threads
This change is enabled in V7.7 with the application of zap 77z410.
Snap formatting changes
Date/time stamps in the page headers of snaps will now be shown in normal format, rather than in Julian format as in previous versions. So in the following example, a particular snap header under v7.7 or previous versions would show as:
SNAPID 1 19226.060155 M204.0022: Bug .. nnnnn PAGE 1
whereas the same snap header under v7.8 would show as:
SNAPID 1 2019/08/14 06:01:06 M204.0022: Bug .. nnnnn PAGE 1
Also, due to improvements in handling trailing blanks in snap output, a snap generated under v7.8 should be marginally smaller than the same snap generated under previous versions, assuming the same SNAPCTL settings.
Call stack trace for problem diagnosis
A call stack trace is now provided to help diagnose and resolve common errors. To enable the stack trace, do either of the following:
- Set the SIRFACT X'01' bit.
- Set the DEBUGL parameter. Note that the DEBUGUL approach will introduce extra QTBL overhead.
(DEBUGUL provides a similar facility with an include trace of procedures leading to the error, but this might not be potentially as useful as the call trace.)
The call stack trace can assist in diagnosing run-time errors that might occur, as illustrated by the following "Variable too small for result" and "MBSCAN exceeded" examples.
Variable too small for result
When the stack trace is enabled, a "variable too small" error results in the following message:
M204.2966: Error at line n, procedure procname in file procfile
which identifies the line within a procedure where the error is occurring, in addition to the usual message:
M204.0552: Variable too small for result
Any subsequent M204.2966 messages indicate the point in the code from where the code in error was called. For example, a stack of three subroutine calls leading to a "variable too small" error might result in the following messaging:
M204.0552: Variable too small for result M204.2966: Error at line 978, procedure DOCOOLSTUFF in file COOLFILE M204.2966: Called from line 1215, procedure FOOBAR.CLASS in file CLASSES M204.2966: Called from line 378, procedure SILLY.CLASS in file CLASSES M204.2966: Called from line 187, procedure P.ROCKANDROLL in file APSYFILE
This information should help in diagnosing the problem.
If the error occurs within a command level program rather than a procedure, then the M204.2966 message is replaced by an M204.2967 message, and a similar error condition to the above with a preceding call stack might be audited as follows:
M204.0552: Variable too small for result M204.2967: Error at line 14 of command level program M204.2967: Called from line 5 of command level program M204.2967: Called from line 3 of command level program
If neither SIRFACT X'01' nor DEBUGUL is set, then the "variable too small" error produces the following messages:
M204.0552: Variable too small for result M204.2968: Error: no debug info
MBSCAN exceeded
Similarly to the handling of the "variable too small for result" error, the call stack can also be used to diagnose errors where the value of MBSCAN is exceeded as a result of a direct search of Table B records.
Again, under V7.8, with either the SIRFACT X'01' bit set or DEBUGUL set, if a long request occurs as a result of exceeding MBSCAN, then initially the following message is produced, as before:
M204.0569: File filename, Find: Table B records to be searched = nnnn
followed by a DYRWT prompt message. If the user replies 'N' to the prompt, or if the request is run in an environment (such as a batch job) where the default response is 'N', the following message is produced after the M204.0569 message:
Cancelling request: M204.2969: MBSCAN (mm) exceeded, records to be searched = nnnn
where mm is the current setting of MBSCAN. The M204.2969 message is followed by M204.2966 messages displaying the call stack trace. Thus, if the following code is run from procedure MYPROC.MBSCAN against the demo database, with an MBSCAN setting of 10:
b call sub1 sub1: subroutine fd1: in clients fd city = ONTARIO end find fr fd1 pai print end for end subroutine end
then the following messages are produced, assuming any prompts are responded to with an 'N':
M204.0569: File CLIENTS, Find: Table B records to be searched = 3415 Cancelling request: M204.2969: MBSCAN (10) exceeded, records to be searched = 3415 M204.2966: Error at line 6, procedure MYPROC.MBSCAN in file MYPROC M204.2966: Called from line 3, procedure MYPROC.MBSCAN in file MYPROC
appendJournalData
The AppendJournalData function is now more tolerant of an outstanding BUMP request. Previously, if AppendJournalData was called to inadvertently retrieve a large amount of journal data, typically when called implicitly from within SirScan, then any outstanding BUMP request wouldn't be honored until all of the data had been retrieved, at which point the BUMP request would be completed, and all data would be lost.
Now, the AppendJournalData process checks for outstanding BUMP requests before each track I/O is executed, thus avoiding excessive I/Os against the journal and long waits for the BUMP of such a process to complete.
Editor enhancements
The Model 204 editor has been enhanced to not hold a lock on a procedure being edited. Instead the timestamp of the procedure on disk is compared against that of the edited procedure when it was loaded or last saved. If different, the save is not allowed. New commands SSAVE, EEND, and GGO are available to force the save in this situation.
In addition, the GO command no longer updates the procedure on disk before INCLUDEing it if it has not been modified in the editor.
AUDIT204 enhancements
FORMAT command
TIMEHH is a new parameter used with the FORMAT command of the AUDIT204 utility. It indicates that timestamps, printed at the beginning of each line of output, should include hundredths of a second. Requires no other arguments.
NOTE: This parameter and the 78 version (or later) of AUDIT204 may be used against a 77 (or later) CCAJRNL.
For example:
//CCAIN DD * FORMAT YEARFORM 4 TIMEHH TYPE ER MS LI
Recovery enhancements
Media Recovery in a multi-user environment
It is now possible to perform media recovery by issuing the REGENERATE command to roll forward selected files in a multi-user environment, with the media recovery being carried out by different users with system manager privileges. The new USING option allows for the specification of a ddname for the input journal stream to be used by the REGENERATE command. Previously media recovery was restricted to single user batch jobs, using the CCAGEN ddname for the input journal. For more details, see the REGENERATE command below.
MERGEJ now supports up to 99 input journals
The MERGEJ utility, used to merge journals with overlapping timestamps prior to running Media Recovery, now supports up to 99 input SORTINnn journals to be merged. For this release it is still the case that any previously merged journal must be defined as SORTIN01 to the MERGEJ run, and thus that the MERGEJ run can not accept more than one previously merged journal as input.
Security enhancements
CA-Top Secret can disallow CCASTAT logins
The CA-Top Secret interface now recognizes the DEFACID=, setting and does not allow CCASTAT logins in the online if DEFACID is set to null. (There is no attempt to log on M204USR.) Therefore, to disallow CCASTAT logons, set DEFACID=, in TOPSPARM. CCASTAT will be opened because it contains file and group passwords, but it will not be used for logons if CCASTAT logons are not allowed.
CUSTOM=11 and mixed cased input
The CUSTOM parameter CUSTOM=11 setting no longer requires that a *LOWER command be issued prior to a LOGCTL command (to add or change a password) to preserve mixed case input. Prior to this release, with CUSTOM=11 in place, *LOWER had to be issued before a LOGCTL command, otherwise any mixed case password strings would automatically be translated into uppercase. This change is enabled in V7.7 with the application of zap 77z108.
DEFUSER can specify a jobname not authorized to access M204
When specifying DEFUSER=JOBNAME and VALIDAT=LOGON in the RACFGEN parms for an ONLINE, if the specified jobname (the owning id for the ONLINE job) isn't authorized to use Model 204 via RACF, any LOGIN commands specifying no userid will now succeed (previously such a LOGON would have failed). This enables users to submit jobs with USE $JOB, whereby the string USER=jobname will be added to the submitted JCL. This in turn is useful if the specified jobname has dataset access privileges to datasets required by the submitted jobs, even if the jobname itself isn't authorized to use M204.
Janus product enhancements
Web API calls available on transactional daemons
Transactional daemons can now use the Janus Web API, mostly $functions that begin with $web. The new $web_api function makes it possible to test if the Janus Web API is available, whether on a Janus Web Server thread or one of its transactional daemons.
Web Sockets
Web Sockets are now supported in Janus Web Server.
The Web Socket protocol provides various advantages over the HTTP protocol:
- Web Sockets allow full-duplex communication.
- Efficient framing of payload data uses minimal overhead.
- The Web Socket protocol is end-user extensible.
- Most importantly, Web Sockets can be deployed completely within an existing HTTP/HTTPS framework.
To implement Web Sockets, you must enable the Janus Web port for Web Socket upgrades with the new WEBSOCKET parameter. The WEBSOCKET option can be specified on either the port definition or the JANUS WEB rule for the URL. Likewise, an individual Janus Web rule can either allow or disallow Web Socket connections with the WEBSOCKET and NOWEBSOCKET parameters, respectively.
For details on implementing Web Sockets, see the WebSocket wiki page.
$Web_Form_Parm_Binary
Janus Web now defers ASCII to EBCDIC translation of form parameter values until a value is requested. This makes it possible to retrieve the exact values sent by the client rather than a translated version. This is important if a form parameter value is UTF-8 encoded and contains non-7-bit ASCII characters (for example if a form parameter contains XML). The $Web_Form_Parm_Binary function returns the exact value sent by a client for a form parameter with no character translation.
Janus Web Server access rule
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 unless overridden by user-added rules.
Note: To revert from this change in the JANUS DEFINE default and make the default non-SSL ALLOW rule as it was in version 7.5 and earlier (
ALLOW *), turn on the 1 bit of the WEBDFLT parameter:RESET WEBDFLT=1
Increase in pending accepts for Janus BPX ports
The default number of pending accepts for Janus BPX server ports has been increased from 3 to 12, thus reducing the likelihood that a pending accept may fail with the message
MSIR.0019 Connection request rejected for port (port), MAXCON exceeded
The actual number of pending accepts to be supported on the port can be set with the new parameter MAXPEND, set on the JANUS DEFINE command, where MAXPEND can vary from 3 up to a maximum value of 32. The change to the default value is enabled in V7.7 with the application of zap 77z269.
TCP listen backlog increased
The TCP listen backlog has been increased from 16 to 1024 under z/OS.
This update tells the TCP stack to queue up a maximum of 1024 such requests before dropping any. This increased backlog reduces, or in most cases eliminates, the likelihood of a connection request drop, other than in exceptional circumstances, such as a denial of service attack. This change is enabled in V7.7 with the application of zap 77z340.
Defer the freeing of XMLSCREEN input XML
The freeing of XMLSCREEN input XML is now deferred until the next Read Screen or session termination. This means that if an application error is detected, the input XML can be retrieved with $Web_Input_Content and then logged for problem analysis.
Prior to this release the XML received from the client was freed immediately after being used to set the input data for a Read Screen, rendering it unavailable for problem determination.
This change is enabled in V7.7 with the application of zap 77z368.
XMLSCREEN and Janus Web Legacy blank stripping
xmlScreens and Janus Web Legacy screens now adhere to the same standard as standard screen processing in terms of stripping leading blanks from input fields defined as DEBLANK (either explicitly or implicitly).
This change is enabled in V7.7 with the application of zap 77z400.
SSL input buffer size
The default value of SSLIBSIZE has been increased to 16384 + 128, or 16512. This size should ensure correct communication with all TLS spec compliant applications. It is the maximum size allowed unless you use CUSTOM=18.
This change is enabled in V7.7 with the application of zap 77z415.
Increasing LDAP buffers
The number of LDAP buffers allocated at startup can now be changed by setting the NLDAPBUF parameter in CCAIN. See below for details on NLDAPBUF.
Increase URL length returned with $web_form_action
With this release the maximum Janus Web Server incoming URL that can be handled by $web_form_action is increased from 512 bytes to 1280 bytes. This change is enabled in V7.7 with the application of zaps 77z424 and 77z448.
Maximum RBSIZE setting increased
The maximum value for RBSIZE, set on the JANUS DEFINE command, is now increased to 16777215 (previously the maximum was 65534). RBSIZE specifies the RPC or Request Buffer size. On a Web port, the Janus request buffer holds browser request information such as header data, cookies, and form data. On other port types, it holds RPC input and output parameters. This change is enabled in V7.7 with the application of zap 77z427.
Debugger enhancements
These enhancements apply to the Janus and TN3270 debuggers.
Access to exposed variables
The debuggers can now view or watch the values of variables exposed to local routines/methods. Previously, any attempts to access an exposed variable would have displayed "%varname has no value" in the debugger session. This feature is enabled in V7.7 with the application of zap 77z363.
Subroutine or method display
When execution pauses for a break point or runtime error, the subroutine or method being executed is indicated in the status area. In addition, the source code line information available by right-clicking on a source line now also indicates the subroutine or method.
Performance enhancements
MP/204 offload improvements
Application code issuing the following SOUL statements will be fully offloadable:
- File Records In/On
- Remember
- Position
- Sort Values
- Reset Header/Trailer
- Find and Print Count
- Find All Values
- For Each Value
The above improvements are enabled in V7.7 with the application of zaps 77z419 and 77z420.
Also, Janus Web rules scanning will be offloadable. In addition, the scan for persistent web sessions ($Web_Form_Done and Janus Web Legacy Support) will be offloadable. While the rendezvous with the persistent thread will still be maintask-only, stateless requests will not need to go back to the maintask to be processed and, even for persistent requests, the persistent session lookup will be offloadable. These changes should provide better scalability for MP/204 sites with heavy Janus Web activity.
X3270OUT exit offloadable
When running MP/204 (AMPSUBS>0) and using the X3270OUT exit to convert a 3270 output data stream to the appropriate device protocol, the exit can now run in parallel mode to improve performance. This change is enabled in V7.7 with the application of zap 77z313.
The X3270OUT exit must be written to be re-entrant.
New and changed commands
MONITOR IODEV
This new command displays the total number, the current usage and the maximum number of each IODEV type.
If the Model 204 parameters include telnet threads (TNDEV parameter), the specified IODEV will actually execute as a daemon thread (SDAEMDEV parameter). For that reason, both the telnet and daemon IODEVs will be incremented and the telnet IODEV will appear with an appended '*'.
M IODEV
Iodev Total Active ( % ) Maximum ( % )
1 1 1 100% 1 100%
7 300 100 33% 150 50%
11 4 0 0% 1 25%
15 500 50 10% 80 16%
25 1 0 0% 0 0%
27 10 0 0% 0 0%
29 10 1 10% 1 10%
51 5 0 0% 0 0%
21* 1 1
DISPLAY ECF
DISPLAY ECF {{ M | N | U } like ?}
This new command displays details from ECF tables, or the current status of users accessing ECF modules.
D ECF M displays the contents of the module table. For example:
D ECF M Module Loadlib Address:Length Loaded@ Lastused@ #Calls Flags QATUM13C PROGLIB 2FB91FB8:00000028 19023:121506 19023:121506 00000001 QATUM13B PROGLIB 2FE65000:00009C18 19023:121506 19023:121506 00000001 QATUM13A PROGLIB 2FE6EC18:00001CD8 19023:121506 19023:121506 00000001
(flags may be D=deleted; S=shared; H=halted; I=Idle)
D ECF N displays contents of the name table. For example:
D ECF N Module Logical-call-name QATUM13C MOD_QATUM13C QATUM13B MOD_QATUM13B QATUM13A MOD_QATUM13A
D ECF U displays details of users currently accessing ECF modules. This is also the default option, and so D ECF will display the same output as D ECF U. For example:
D ECF U User# Userid Module Parmlen 00002 ADMIN --none-- 00003 ADMIN COBSAMP1 00000002 00004 ADMIN COBSAMP1 00000002
D ECF function LIKE ? (where ? is a valid pattern) displays details for entities that match the specified pattern. The function is either M (modules), N (names), or U (users), and it defaults to U. So for example:
D ECF U L A
or
D ECF U L A*
displays details of ECF users whose names begin with A.
REGENERATE
The REGENERATE command can now be run in a multi-user environment by multiple users with system manager privileges. A new option USING is provided to specify the ddname of the input journal, so that the full syntax is now as follows:
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE] [TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th] | LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th] | UPDATE number OF yy.ddd hh:mm:ss.th | CHECKPOINT yy.ddd hh:mm:ss.th} ]
The default for the using ddname is CCAGEN, but any ddname may be used to allocate an input journal and used. For example:
ALLOCATE REGEN1 WITH SCOPE=SYSTEM DSN=PROD1.GDGJ OLD SEQUENTIAL GEN=+2 REGENERATE USING REGEN1 FILE TEST
It is the user's responsibility to ensure that the file being regenerated is not in use, and so prior to usage, BUMP FILE and STOP FILE should be used to isolate usage against the file. If the file is in use, the REGEN will fail with these messages:
M204.1430: Failed to open file TEST M204.1436: Stopped processing file TEST
$STATUS will now be set for REGENERATE with the following values:
0 - Success
1 - No files were processed
2 - At least one file stopped processing
4 - A serious error occurred, REGEN failed
Similarly, SETGRC may be used to get the return code and error message.
New and changed parameters
COMMITX
The commit exit runs within the APSY defined by the COMMITX parameter and uses normal APSY processing.
The new parameter COMMITX is settable from User 0's parameter line or by the system manager. It can be reset at any time by the system manager.
Setting/Resetting the parameter sends a DYRWT message to the issuer and requires a Yes or No response (unless set/reset by user0).
If COMMITX is specified, all APSY subsystems participate by default but any can be exempted.
ECMSUBS
This maximum value may now be reset dynamically by a system manager. If the value is raised, new tasks will be added as needed up to the value specified. If the value is lowered, idle subtasks will be detached before they are activated until the new maximum is established.
ECMODS
The new minimum value for ECMODS, the allowable number of ECF modules, is 1. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.
ECNAMES
The new minimum value for ECNAMES, the allowable number of ECF module names, is 1. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.
ECPSIZE
The new minimum value for ECPSIZE, the initial storage allocation for ECF parameters, is 1024. Prior to V7.8 the minimum value was 0. This change is enabled in V7.7 with the application of zap 77z306.
ENQTIME
Millisecond duration of automatic record locking retry wait.
Prior to this change, if record locking conflicts occur frequently in a busy online, any user with a non-zero value for ENQRETRY will wait at least 3 seconds before the conflict is dealt with. This can degrade overall system performance.
The ENQTIME parameter specifies the number of milliseconds waited for each record locking retry wait. ENQTIME can be between 1 and 60000, corresponding to a minimum of 1 millisecond and a maximum of 1 minute. The default value of ENQTIME is 3000 (3 seconds).
For example, with ENQTIME = 100 and ENQRETRY = 7, after a record locking conflict occurs the thread will retry 7 times with wait intervals of .1 seconds, and so within at most .7 seconds either the lock becomes available or the conflict triggers an On unit or cancels the request.
The ENQTIME parameter may also be reset with $ResetN.
This new parameter is enabled in V7.7 with the application of zap 77z299.
EVALOPT
The new EVALOPT parameter controls the cancellation of a request on truncation of string data. The default value is 0, and currently there is just one setting, 1, which means "cancel a request if truncation of string data occurs."
For example, with the default of 0 in place, the following code
%x is string len 1 %y is string len 2 %y = 'ab' %x = %y printtext {~} = {%x}
would cause silent truncation, and give the result
%x = a
If EVALOPT is set to 1, then the above code produces the following message:
M204.0552: Variable too small for result
and the request is cancelled.
LFSCB
LFSCB, the length of the full screen buffer, now has a new minimum value of 8 (the previous minimum was 0). This change is enabled in v7.7 with the application of zap 77z042, and within V7.6 with the application of zap 76z393.
MAXPRE, MAXBOUT, MAXSUBT
Introduced in zap 77z257.
The new MAXPRE, MAXBOUT, and MAXSUBT parameters can be used to cancel a runaway transaction and prevent it from filling the checkpoint data set.
- MAXPRE: Maximum number of pre-images per transaction.
- MAXBOUT: Maximum number of backout pages per transaction.
- MAXSUBT: Maximum number of subtransaction checkpoints that a transaction can span.
Each new parameter defaults to unlimited.
If a parameter value is set, a transaction is cancelled if that value is exceeded, and the following message is displayed:
M204.0524: Maximum number (num) of parameter exceeded.
where num is the value set for parameter (MAXPRE, MAXBOUT, or MAXSUBT).
MQMXTASK
This maximum value may now be reset dynamically by a system manager. If the value is raised, new tasks will be added as needed up to the value specified. If the value is lowered, idle subtasks will be detached before they are activated until the new maximum is established.
NLDAPBUF
This new parameter allows the number of LDAP buffers allocated during startup to be set in CCAIN. The default value is 2, and the settable value can range from 0 to 65535.
PUPDTH (new minimum value)
If a user sets the PUPDTH parameter to 0, it will now automatically be increased to 1, its minimum value.
SERV4G
This parameter allows testing of server tables that span a 4-gigabyte boundary. For example, if SERV4G is X'FFFFF000', each ATB server will begin at XX_FFFFF000. If SERV4G is X'FFFF0000', each ATB server will begin at XX_FFFF0000. XX is determined by the storage available on the system. The parameter is set in CCAIN.
The contents of the ATB server are specified by using the SERVGA parameter.
For example, if you want VTBL to span the 4G boundary, you can use these settings: SERV4G=X'FFFFF000', SERVGA=X'00040000', and LVTBL=200 (6400 bytes, X'1900'). This will force each server's VTBL to begin at XX_FFFFF000 and end at XX+1_00000900.
SIRTERM
The SIRTERM (Sirius terminal options) parameter settings have changed. The changes to SIRTERM allow a user to preclude a reset to a Model that is not supported by the terminal emulator in use.
The X'01' setting (MODEL 6 support) is no longer used.
The X'02' setting (Write Structured Field Query Support) now supports MODEL 6 terminals by default.
The new X'08' setting always issues a Write Structured Field Query for Terminal Model Resets for terminals connected to Model 204 through VTAM or TELNET, provided that X'02' has been set. This precludes Terminal Model RESETs to Models that are not supported by the terminal emulator in use.
WEBDFLT
At V7.7, the default access rule for non-SSL ports was changed from ALLOW * to DISALLOW *, meaning that unless any ALLOW rules were in place resulting in a login/password prompt, the port couldn't be accessed. The new WEBDFLT parameter may be set to 1 for reversion to the old default of ALLOW *. This new parameter is enabled in V7.7 with the application of zap 77z090.
RESET WEBDFLT requires system administrator privileges. It is recommended to reset the 1 bit of WEBDFLT to zero after issuing a series of JANUS DEFINE commands which need WEBDFLT=1, as in the CCAIN input stream.
New and changed statistics
MPR, MBO, MCP, and RCV
Introduced in zap 77z257.
These statistics provide high water mark transaction information. (Since-last values will not be available until V78 GA.)
They are useful in conjunction with the MAXPRE, MAXBOUT, and MAXSUBT parameters.
User/system statistics:
- MPR: High water mark of transaction pre-images.
- MBO: High water mark of transaction backout pages.
- MCP: High water mark of transaction chkpoint spans.
System statistics:
- RCV: Number of blocks needed for subtransaction recovery
Notes: M204.0843 now displays the RCV statistic for subtransaction checkpoints. The size of recovery checkpoint must be greater than the sum of the last RCV value plus the number of records in RESTART and RESTARTS.
DKWTS and DKWTMICS
Introduced in zap 77z7289.
The new system statistics DKWTS (DisK WaiTs) and DKWTMICS (DisK WaiT MICroSeconds) collect data to provide rough disk I/O service time numbers.
DKWTS shows the number of disk I/O waits. DKWTMICS shows the total wait time for those waits in microseconds. Dividing the difference in DKWTMICS by the difference in DKWTS over an interval provides the average disk I/O wait time in microseconds.
Notes:
- The wait time does include internal Model 204 scheduler delays, so on a CPU bound Model 204 system, the service times calculated from DKWTS and DKWTMICS are likely to be an overestimate of actual service times.
- DKWTS and DKWTMICS are not available in SirMon; use MONITOR SYSTEM STATISTICS to view these statistics.
Compatibility issues
$ListNew cannot be used in Initial clause
It is now a compilation error if $ListNew is attempted to be used in the Initial clause of a declaration statement.
This change is propagated by zap maintenance to versions 7.5 (zap 75Z487), 7.6 (zap 76Z514), and 7.7 (zap 77z281) of Model 204.
Note: Strictly speaking, this would not be considered a compilation error, because previously although
.. Initial($ListNew)did not produce a compilation error, in almost all circumstances it would produce a snap if the initialized %variable were used with some other $Listxxx invocation.
Restricting the use of the CUSTOM=38 setting
The CUSTOM=38 parameter setting, introduced at V7.5, inadvertently provided System Manager privileges to all users via the RESET command. This CUSTOM setting is now restricted to the RESET of the LAUDIT parameter.
Disabling of Closure support
Due to a non-trivial backward incompatibility issue related to Closure support, introduced in V7.7, this feature, which can best be described as exposed methods assigned to method variables, has been disabled in this release. This change was also made to V7.7 with application of zap 77z119.
Password delimiter enforced
When using IFSTRTN to log on to a Model 204 online from an IFAM2 application, both the logonid and password must be followed by a semicolon, which is the delimiter. For example:
CALL IFSTRTN(RC,'logonid;password;'...)
If a semicolon does not follow the password string, the following message will now be issued:
M204.2964: Password missing or too long
Previously, a semicolon following the password was not required and the first blank served as a password delimiter. However, as of V7.7, embedded blanks are valid password characters and a semicolon is now required to delimit the password.
This change is enabled in V7.7 with the application of zap 77z231.
PAGESZ parameter validated
Previously it was possible to set the PAGESZ parameter to any value, although Model 204 internally supports one page size of 6184, and any deviation from this value would have led to problems during file creation. The value of this parameter is now controlled, such that setting it to any value other than 6184 will generate an M204.1149 message with the parameter being reset to 6184.
ECPRIV and the IDCAMS facility
At V7.7 a security loophole was closed, whereby all ECF modules were run under external-authorizer profile of the calling user. Previously any ECF tasks were run under the owning job's external-authorizer profile, and in order for certain sites to retain that ability, a new setting of ECPRIV, value 4, was introduced to retain the ability to run ECF tasks using the job's security profile.
The ECPRIV 4 setting potentially introduced a security loophole when calling the IDCAMS interface, based upon what the IDCAMS utility is able to do at a system level. Consequently as of this release, the ECPRIV 4 setting will be ignored when calling the IDCAMS facility via ECF, and such IDCAMS processes will always use the calling user's security profile. Any existing jobs that use ECF to call the IDCAMS utility with the ECFPRIV 4 bit set should be checked to ensure that the calling user's security profile still satisfies the job's requirements.
TCPOPTS is view-only
In previous versions the TCPOPTS parameter, which identifies the type of IP addressing in use (v4 or v6), was resettable, although it was always documented as a view-only parameter. The parameter is now handled as a view-only parameter, and any attempts to reset the parameter will result in the following message:
M204.1123: Parameter TCPOPTS not reset
ZHPF command can only be issued by a system manager
In previous versions it was possible to issue the ZHPF command without being logged on. From this release onwards, a user must be logged on with system manager privileges in order to issue this command.
Additionally, the command output will now only display results for currently open files.
This change is enabled in v7.7 with the application of zap 77z264.
Terminal MODEL reset failure
If a reset of the terminal MODEL parameter fails due to an undersized output page buffer, then in addition to the existing messages that inform the user of this failure:
M204.1875 UNABLE TO RESET MODEL TO %C M204.1123: Parameter MODEL not reset
the following message will now be issued:
M204.1008: LOUTPB must be increased to at least <number>
where <number> is the minimum value of LOUTPB necessary to support the terminal model.
This change is enabled in V7.7 with the application of zap 77z309.
BUF and FBMX stats removed
Unnecessary scans of the buffer pool have been eliminated from most forms of the MONITOR command ( other than MONITOR DISKBUFF itself ), and this provides performance gain when running these commands. However, as a result of this the BUF stat on the MONITOR command output, and the FBMX stat reported in the system final stats block have been removed. These stats were of extremely limited value, and their elimination should not cause any problems for system management. This change is implemented in V7.8 via zap 78z077, and in V7.7 by zap 77z463.
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 products
Janus Two-Phase Commit
Janus Two-Phase Commit support makes it possible to create global transactions where updates on multiple Model 204 Onlines or Imagine can be atomically committed or backed out.
Commit Exit
The Commit exit product allows for the invocation of specified APSY code when an an APSY TBO transaction executes its first explicit or implicit COMMIT. The feature is controlled by the new COMMITX parameter.
New and changed messages
See New and updated messages in Model 204 version 7.8 for details.