Release notes for Model 204 version 7.8

These release notes list the enhancements and other changes contained in Model 204 version 7.8.

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	The new AmIndependent method returns TRUE for daemons spawned by RunIndependently. The Object class now supports the copy and deepCopy methods.
Janus Web	Janus Web Sockets are now supported.
Networking	Two-phase commit. A Model 204 online can now be configured to use two-phase commit (2PC). The Janus internal socket API is used for the calls to the coordinator. JANUS commands are used for all 2PC configuration. A new JANUS port type has been added: 2PC. Commit exits are now supported. The commit exit runs within the APSY, which is defined by the COMMITX parameter and uses normal APSY processing.
ECF tables	The new DISPLAY ECF command and EXTERNAL REMOVE statement enable more efficient management of ECF tables.
Performance	MP/204 offload improvements -- application code for these SOUL statements is now fully offloadable: File Records In/On Remember Position Sort Values Reset Header/Trailer Find and Print Count Find All Values For Each Value
Security	CA-Top Secret can disallow CCASTAT logins. DEFUSER can specify a jobname not authorized to access M204.
System enhancements	The MONITOR USERS command output displays two new wait types.
AUDIT204 enhancements	The new TIMEHH parameter on the FORMAT command of the AUDIT204 utility provides greater time stamp precision.
New commands	DISPLAY ECF displays details from ECF tables, or the current status of users accessing ECF modules.
New parameters	ENQTIME specifies the number of milliseconds waited for each record locking retry wait. EVALOPT controls the cancellation of a request on truncation of string data. MAXPRE, MAXBOUT, and MAXSUBT can be used to cancel a runaway transaction and prevent it from filling the checkpoint data set. NLDAPBUF allows the number of LDAP buffers allocated during startup to be set in CCAIN. SERV4G allows testing of server tables that span a 4-gigabyte boundary. WEBDFLT changes the default JANUS WEB ALLOW rule back to ALLOW.
Janus and TN3270 debuggers	The debuggers can now view or watch the values of variables exposed to local routines/methods. When execution pauses, the debuggers now display the subroutine or method being executed.
User/system statistics	MPR, MBO, MCP, and RCV provide high water mark transaction information in conjunction with the MAXPRE, MAXBOUT, and MAXSUBT parameters. New system statistics DKWTS (DisK WaiTs) and DKWTMICS (DisK WaiT MICroSeconds) collect data to provide rough disk I/O service time numbers.

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.)

  Version 1.07 is sufficient for all functionality except for the following features:

  • zHPF support requires version 2.1.
  • Large (1 MB) page support requires version 1.9.
  • Extended address volumes (EAV) requires version 1.12.

  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.

• 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.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 DEBUGUL 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.

This change is also enabled in V7.7 with the application of 77z487.

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.

Limiting the production of MSIR.0019 and MSIR.0020 messages

The production of the following messages

MSIR.0019 Connection request rejected for port (port), MAXCON exceeded

MSIR.0020 Connection request rejected for port (port), no SDAEMONS available

is now limited to a maximum of one each per time interval set by the MAXAUSEW parameter ( minimum seconds between MAXAUSER warnings, which defaults to 10 seconds ). This avoids flooding the journal / jlog with these messages in situations where the number of connections on a port has been exceeded ( MSIR.0019 ), or the the number of available daemon threads has been exceeded ( MSIR.0020 ).

This change is available in V7.8 with the application of zap 78z011, and within V7.7 with the application of 77z466

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.

Internal performance improvements

A number of internal performance and optimisation improvements have been made in this release. these include

• Sampling buffer pool pages rather than carrying out a full scan of large buffer pools ( NUMBUFG > 200000 ) when calculating BUFFnnn stats for SirMon
• Optimising group and file closure, in particular providing relief on exit from APSYs where a lerga number of groups may be in use, and where the groups may comprise a large number of file members
• Improved handling of timer queues, particularly in an MP/204 environment
• More aggressive prioritisation of journal and checkpoint I/O, in order to reduce user waits for such I/), and to reduce related waits on critical file resources

New and changed commands

MONITOR

The MONITOR command output now contains a new column, headed LOG, that shows the logon status of each user in the system, for example

USER SVR FLS PCPU SMPLS RUNG REDY BLKI WTSV BLKO SWPG 7 0.330 USER SVR USERID P CUR SLICE LOG FUNC CNCT CPU SEQIO QUE WT FLGS 0 1 SUPERKLUGE S 56 0.031 CCA EVAL 5 0.012 221 OFFI 12 65 4 2 ADMIN S 51 0.031 CCA 1 0.000 22 RUNG 20 VT75DIED 0.000 0 0.000 0 2 20 21 VT75READ 0.000 37 0.000 0 3 00 22 VT75ERRS 0.000 0 0.000 0 2 20 23 CHKPTIMO 0.000 0 0.000 0 12 20 24 CHKPTIMR 0.000 0 0.000 0 12 20 25 CHKPPST 0.000 0 0.000 0 12 20 26 CHKPAWW 0.000 0 0.000 0 12 20 27 TC62RAPS 0.000 0 0.000 0 27 04 28 TC62SRVC 0.000 0 0.000 0 27 20 >

The LOG column replaces the AGE column in the MONITOR output, as this information was considered more relevant for this command output. Possible values that are shown in the LOG column are as follows

• CCA - CCASTAT userid
• ESM - userid validated by an External Security Manager - ACF2, RACF, or TopSecret/li>
• SUB - Subsystem controlled logon
• GST - Guest - neither logged on via CCASTAT nor by an ESM
• PDG - Logon pending due to errors (e.g. invalid password)

This change is also available with V7.7 with the application of zap 77z478.

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).

MODENAME in a Transfer Control PROCESSGROUP

Previously the MODENAME parameter has been ignored in VTAM TRANSFER PROCESSGROUP processing.

As of V78 with 78Z029 applied, Users will be able to control the characteristics of a session (for example, Display Model, Ru size, EDS support et al.) bound at the VTAM Transfer Control Target by means of the VTAM Transfer PROCESSGROUP's MODENAME.

A null or unspecified MODENAME in a VTAM Transfer PROCESSGROUP definition will result in the Target LU's Default LOGMODE being used to Bind the Target Session (This is how all VTAM Transfers worked previously).

Specifying MODENAME=LOGON or MODENAME=LOGIN in a VTAM TRANSFER PROCESSGROUP definition results in the LOGMODE used to Logon to the Source Online also being used to Bind the Session at the Transfer Target.

Otherwise, anything specified in a VTAM TRANSFER PROCESSGROUP MODENAME parameter will be assumed to be a valid VTAM LOGMODE and will be used to Bind the Transferred session at the Target. There is a potential for upward incompatibility in the case where a VTAM TRANSFER PROCESSGROUP definition specifies an invalid value for MODENAME:

Since the MODENAME is no longer ignored, an invalid value will now fail the Transfer.

A failed Transfer consequent to an invalid LOGMODE or a LOGMODE unknown at the Target is flagged with: M204.2483 'unknown-modename is not a valid LOGMODE name'.

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.

WEBOPT

The new x'10' setting of WEBOPT allows transaction daemon threads to access web data owned by the ancestor ( usually the parent ) thread.

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.