m204wiki - User contributions [en]

Security Server (formerly RACF) interface

2015-09-16T19:48:29Z

Teagan: spelling correction (t to the)

==Overview==
This topic presents an overview of how Security Server works and describes the impact of the Security Server Interface on the Model 204 user, system manager, and Security Server security administrator.

Note: The Security Server interface was formerly known as the RACF interface.

===Security Server===

Security Server is an extension of the IBM z/OS operating system that provides comprehensive data security. The Security Server Interface allows a Model 204 installation to use Security Server services within the Security Server environment. 

===Model 204 Security Server Interface===

The Model 204 Security Server Interface allows an orderly migration from Model 204 security to Security Server security and allows an installation to use a combination of either or both security methods. The interface provides the tools and instructions necessary to: 

<ul>
<li>Define a Security Server control group so that Model 204 can distinguish between separately running copies (that is, test and production)
</li>

<li>Define Security Server generic profiles for Security Server authorization of Model 204 user privileges within a control group
</li>

<li>Define a generic profile within Security Server that is associated with a control group, and determines whether a user can log in to Model 204
</li>

<li>Define a Security Server common control group for Model 204 resources that can be shared between running copies
</li>

<li>Define a default user priority class, or define the Security Server generic profiles that permit certain users to have specified Model 204 priorities
</li>

<li>Provide a mechanism to validate accounting information
</li>

<li>Determine a generic profile within Security Server that can define whether a user is allowed to submit JCL through the USE command
</li>

<li>Allow a system manager to add, change, or delete Security Server Interface options that control interface operations
</li>

<li>Provide a mechanism that establishes a shadow login capability to restrict user authorization via a default user ID for users who do not log directly in to Security Server
</li>

<li>Provide a method for a Security Server security administrator to define a default group, user ID, and password for the default user ID
</li>

<li>Provide a method for a Security Server security administrator to force users to log in through Security Server and not through
CCASTAT
</li>
</ul>
===Model 204 Security Server Interface components===

In summary, the Security Server Interface provides all the facilities an installation needs to implement Security Server security within the Model 204 environment. 


The following figure illustrates the components of the Security Server Interface. 

<center>
[[File:SECURITY_Security_Server_interface.jpg|border|450px]]
</center>

Security Server Interface

The Security Server Interface consists of the following components: 

<table>
<tr><th>Component</th> <th>Notes</th></tr>
<tr>
<td>Model 204 </td>

<td>Links with the Security Server Interface module </td>
</tr>

<tr>
<td>Security Server Interface module, RACFOS</td>

<td>Communicates with Security Server by using the System Authorization Facility (SAF) z/OS router</td>
</tr>

<tr>
<td>RACFPARM module </td>

<td>Can be linked with Model 204 or loaded dynamically at initialization</td>
</tr>

<tr>
<td>Model 204 system file, CCASTAT</td>

<td>Contains file protection passwords, user IDs, and user ID passwords</td>
</tr>

</table>

==Brief introduction to Security Server==

This section provides a brief summary of key Security Server features that are used in the discussion of the Model 204 Security Server Interface. 

For more information about the Security Server, see the [http://www-03.ibm.com/systems/z/os/zos/features/racf/resources.html IBM documentation] associated with that product. 

===Security Server processing===

Security Server identifies and verifies users accessing a system in which Security Server is installed and determines whether or not the user: 

<ul>
<li>Is defined to Security Server
</li>

<li>Has supplied a valid password (and/or operator identification card) and group name
</li>

<li>Has the REVOKE attribute, which prevents a Security Server defined user from entering the system at all or from entering the system with certain groups
</li>

<li>Can use the system only at certain times or on certain days as specified by the system manager or Security Server security officer
</li>

<li>Is authorized to access the terminal (which also can include day and time restrictions for accessing that terminal)
</li>

<li>Is authorized to access the application
</li>
</ul>

The following types of checking are performed by Security Server:
<ul>

<li>Authorization
</li>

<li>Global access
</li>
</ul>

===Authorization checking===

When Security Server verifies a user’s identity, Security Server specifies the scope of that user’s authorization for the current terminal session or batch job in a control block called the accessor environment element (ACEE). Security Server controls the interaction between the user and protected resources and authorizes not only which resources the user can access, but the way in which the user can access them (for example, as read-only or update). 

At the start of processing, Security Server performs the following checks that are related to the security classification of users

and data: 

<ul>
<li>Compares the security level in the user and resource profiles. If the resource has a higher security level than the user, Security Server denies the request.
</li>

<li>Checks a category list (that is, a list of site-defined names corresponding to departments or areas within an organization) in the user’s profile against the category list in the resource profile. If the resource profile contains a category that is not in the user’s
profile, Security Server denies the request.
</li>
</ul>

If Security Server has not denied the request as a result of the security classification checks, processing continues. 

Security Server permits access to a resource if the user satisfies any of a number of conditions, such as the following: 

<ul>
<li>The resource is a data set and the high-level qualifier is the user’s user ID
</li>

<li>The user’s user ID is in the access list with sufficient authority
</li>

<li>The user’s current connect group is in the access list with sufficient authority
</li>

<li>When list-of-group checking is active, one of the other groups with which the user is connected is in the access list with sufficient authority
</li>

<li>The universal access authority (UACC) is sufficiently high
</li>

<li>The user satisfies both of these conditions:
<ul>
<li>The user has the OPERATIONS attribute or the resource is within the scope of a group in which the user has the group-OPERATIONS attribute</li>
<li>The user’s user ID or any group name the user is connected to is in the access list with an authority not less than the user’s intended access</li>
</ul>
</li>
</ul>

Security Server provides two installation exits that a site can use during RACHECK processing, as well as a quicker form of
authorization checking called FRACHECK, or fast path RACHECK processing. 

===Global access checking===

In addition to authorization checking, Security Server also provides global access checking. Global access checking allows a site to store a system-wide table of default authorization levels for selected resources. Security Server checks this table to determine if access to a resource is permitted.

If access is permitted, Security Server bypasses further RACHECK processing. If the global access check fails, RACHECK processing continues. Frequently accessed resources with generalized access rules are good candidates for global access checking.

Global access checking handles resources in both the data set and the general resource classes, with the exception of group
resource classes.

Global access checking does the following:

<ul>
<li>
Grants access, but does not, by itself, deny any request for access
</li>

<li>
Does not allow logging of permitted access or gather statistics
</li>

<li>
Does not offer a postprocessing installation exit
</li>

<li>
Performs no I/O on the Security Server data set, thus offering a high-performance checking option
</li>
</ul>

===Using profiles to protect resources===

Security Server protects data sets (both DASD and tape) and general resources such as tape volumes and terminals. These
resources are protected through profiles defined by the site. Authorized users can create, modify, list, and delete profiles using
Security Server commands. 

When the ADDSD statement is used to define and protect a data set, Security Server builds a data set profile and stores it in the Security Server data set. Profiles can be either generic or discrete depending on the nature of the resource. 

===Generic profile===

A generic profile protects a single resource such as one data set, or a number of related resources; for example, those having similar naming structures, or the same access, authorization, and auditing requirements. 

A generic profile contains a list of authorized users and the access authority of each user. A single generic profile can protect
many data sets that have similar naming structures. Data sets protected by generic profiles need not be defined individually to
Security Server, which saves the system manager from having to enter and maintain individual profiles. 
Many users can protect all their data sets with a single generic profile consisting of their user ID and an asterisk: 
user_id.*


This profile protects all the user’s data sets that begin with the user’s user ID, regardless of the number of qualifiers. 

===Discrete profile===

A discrete profile protects resources that have specific or unique access authorization or logging requirements such as a single sensitive data set on a specified volume. 

A discrete profile contains the same kind of information as a generic profile, but it protects only the one identified data set on the specified volume or volumes. 

If the access authorization requirements are general, define a generic profile. If the data set has unique access authorization
requirements, define a discrete profile. 

Either type of profile can protect tape data sets as well as the following: 

<ul>
<li>
Cataloged and uncataloged non-VSAM data sets
</li>

<li>
VSAM data sets
</li>

<li>
Data sets with the same name residing on different volumes
</li>

<li>
Generation data group (GDG) data sets
</li>

<li>
Data sets and catalogs with single level names via a site-supplied prefix
</li>
</ul>

In Model 204, the Security Server Interface user privileges and other authorization items are defined as data set names and
treated as system resources. Generic profiles control who can use those resources by permitting individual users to access them.
These rules are written by the Model 204 system manager and the Security Server security administrator. 

==Running the Security Server Interface with Model 204==

When running either as an Online or in batch mode, Model 204 checks Security Server for the system resources a user has
permission to access. Model 204 manages the authorization process, because only Model 204 can identify the user requesting a
resource. Model 204 asks Security Server to validate those requests and responds to users who have been denied requests for
resources. 

Model 204 interfaces with Security Server in the following distinct areas: 

<ul>
<li>
User logins

<ul>
<li>LOGIN/LOGON command
</li>

<li>IFSTRT function
</li>

<li>IFLOG function
</li>
</ul>

</li>

<li>User resource requests

<ul>
<li>Dynamic allocation of new DASD space (ALLOCATE command)
</li>

<li>Job submission (USE $JOB command)
</li>

<li>Sequential data set handling (Record I/O)
</li>

<li>VSAM data set handling (External I/O)
</li>
</ul>
Note: Because Model 204 databases are not validated on behalf of the user by the security interface, Security Server must grant the owner of an address space permission to open Model 204 file data sets for update, regardless of whether the owner has write or read-only privileges. 
This permission allows Model 204 to write back updates to the FPL (File Parameter List) page, as required by the database management system, regardless of the Model 204 file open privileges.
</li>

<li>User logouts

<ul>
<li>LOGOUT/LOGOFF command
</li>

<li>IFFNSH/IFDTHRD function
</li>
</ul>
</li>
</ul>

The Security Server Interface uses the standard IBM-supplied calls to validate user requests for Model 204 resources. No source code modifications or exits to the Security Server software are needed. However, you can define an additional Security Server control group for nonshared resources as well as for resources shared between multiple copies of Model 204. 

==Using the Security Server Interface==

This section describes the changes that affect a Model 204 user. They include: 

<ul>
<li>LOGIN or LOGON
</li>

<li>IFSTRT function
</li>

<li>IFLOG function within IFAM1
</li>

<li>Dynamic allocation
</li>

<li>Job submission
</li>

<li>Sequential and VSAM data set handling
</li>
</ul>
===LOGIN or LOGON command===

The LOGIN/LOGON command allows you to gain access to Model 204. Once you are connected to Model 204, and if the system manager has set Model 204 to require logins, any commands you enter (other than LOGIN or LOGON) produce the following message: 

*** PLEASE LOGIN


To log in, enter: 

LOGIN userid [account]


or


LOGON userid [account]


where: 
<table class="noBorder">
<tr>
<td><var class="term">userid</var></td> <td>Is a character string that identifies you.</td> </tr>
<tr><td><var class="term">account</var></td> <td>Is an optional character string that identifies the account under which you log in.</td> </tr>
</table>
===User ID information===

If Model 204 provides security authorization checks, as a Model 204 user you are assigned the following by the system manager: 

<ul>
<li>User ID that identifies you to Model 204
</li>

<li>Password that provides access to the system
</li>

<li>User privileges associated with your user ID and password to define the particular type of access that you have
</li>

<li>Default priority class assigned to your user ID
</li>
</ul>

When native Model 204 security is in effect, this ID information is stored in a record in the system file CCASTAT. This record is deleted from CCASTAT when the system manager moves the user into Security Server security mode.
The [[#Preparing a RACFPARM parameter module with RACFGEN|RACFPARM]] module supplies a default Logonid for CCASTAT Logonids to do validation requests on Security Server.

===Security Server processing===

When Security Server performs login validation, the user ID must be eight characters or less (seven characters if jobs are
submitted through the internal reader). Your user ID is verified by Security Server before you can log in to Model 204. 

If your site chooses to perform Security Server account validation, any value entered in the account field is verified via Security Server services. When Security Server is performing account validation, the account is limited to a maximum length of eight characters. If you do not enter an account, the default account becomes your user ID. Refer to [[#Login processing|Login processing]] for more information on login processing. 

If you have the appropriate authority, you can change your Security Server user ID password when you log in to Model 204. For more information about the LOGIN and LOGON command, refer to the [[LOGIN or LOGON command]] wiki page.

===IFSTRT function===

In the IFAM1 and IFAM4 environments, the IFSTRT function is used in a Host Language Interface program to allocate a Host
Language Interface thread. IFSTRT also establishes the calling convention, performs a user login, and determines whether or not the thread has updating privileges. 

When processing the login argument of the IFSTRT call, the user login process follows the rules for [[#User 0 login|User 0 login]].

===IFLOG function within IFAM1===

The IFLOG function is used only in the IFAM1 environment. It is called following IFSTRT to identify you when a login is required.

This function is necessary in any IFAM1 program where user authorization is validated by Security Server. 

As with the IFSTRT function, the user login process is the same as the process for
[[#User 0 login|User 0 login]].

===Dynamic allocation considerations===

All dynamic allocation services in a Security Server environment are subject to Security Server system rules for data set
validation. For example, data set allocation can be restricted to allow the creation of data sets with certain name patterns. The rules for data set access are determined by the Security Server security administrator. 

To dynamically allocate a new data set, you must have Security Server ALTER authority. If you issue an ALLOCATE command
and you do not have ALTER authority, you receive a Model 204 error message. 

If you log in to Model 204 via CCASTAT, your allocation privileges are determined by the Security Server default user’s
authorization. 

Note: When you open a new or existing sequential or a VSAM data set, it is validated for read/write access. Security Server does not perform open access authorization on Model 204 data sets, because these data sets are currently protected under Model 204 security. 

===Job submission considerations===

When an Online user issues the USE $JOB command to submit a batch job, Model 204 identifies the user so that Security
Server can determine if the user has proper authorization. If the submitter is IFAM1, IFAM4, or User 0, no additional processing
occurs; the submitted job inherits the privileges from the submitting job, because it has already been authorized to run by Security Server. 

In a Model 204 system in which the Security Server Interface is running, the following JCL statement is appended automatically
to the submitted job statement(s) to identify the Model 204 user: 

// USER=userid,PASSWORD=password,GROUP=groupname


where: 
<table class="noBorder">
<tr>
<td><var class="term">userid</var></td> <td>Is the submitting user’s Security Server user ID, or the default user ID if the user is logged in through CCASTAT.</td> </tr>

<tr><td><var class="term">password</var></td> <td>Is the user password associated with the particular user ID, or the default password for the default user ID if the user is logged in through CCASTAT.</td> </tr>

<tr><td><var class="term">groupname</var></td> <td>Is the Security Server group to which the submitting user is assigned. This is the group identified in the user’s ACEE that is provided by Security Server during user login, or the default group if the user is logged in through CCASTAT.</td> </tr>
</table>

The default user ID, password, and group information is defined in the Security Server Interface parameter module (RACFPARM) and cannot be modified by the user or controlled by the system manager. RACFPARM is described later in this section. 

If Model 204 finds any of the Security Server control parameters listed previously while processing the submitted JOB, they are
deleted from the JCL to prevent users from violating security. 

An installation can request that Model 204 check for user authority to submit a job. Because Security Server does not have a
facility to restrict job submission, Model 204 checks the generic profile for the comgroup.SUBMIT option. Comgroup.SUBMIT
determines whether or not a user is permitted to submit JCL. For more information about comgroup.SUBMIT, refer to the [[#Preparing a RACFPARM parameter module with RACFGEN|RACFGEN macro]] discussion.


If an unauthorized user attempts to submit a job, Model 204 issues an error message. 

For users logged in via CCASTAT, the authority to submit jobs is determined by the default user’s authorization. 

===Sequential and VSAM data set considerations===

Security Server always performs an authorization check if you try to use a sequential or VSAM data set. To use a sequential or
VSAM data set you must be a member of a control group (or optionally a common control group) that has: 

<ul>
<li>Security Server alter or update privileges to open a deferred update data set or to issue the DUMP or USE commands
</li>

<li>Security Server alter authority to dynamically allocate a new sequential data set
</li>

<li>Security Server read privileges to read sequential files from User Language or to read the file specified in a RESTORE command
</li>

<li>Security Server read privileges to read external VSAM files from User Language.
</li>
</ul>

If you issue a sequential or VSAM data set OPEN command that fails for Security Server reasons, Model 204 issues an error
message. 

If you log in to Model 204 via CCASTAT, authorization is determined by the default user’s authorization limits. 

Model 204 sequential file data sets (such as CCASTAT, CCAAUDIT, CCAJRNL, or CCAJLOG) are also checked to determine if the owner of the address space has the authority to write to them. 

Security Server directly checks the following Model 204 commands: 
<ul>
<li>
[[DUMP command|DUMP]] and [[DUMPG command|DUMPG]]
</li>

<li>
[[RESTORE command|RESTORE]] and [[RESTOREG command|RESTOREG]]
</li>

<li>
[[USE_command:_Directing_output|USE OUTXXXXX]]
</li>

<li>
[[ALLOCATE command|ALLOCATE]] a new data set
</li>

<li>
OPEN DATASET
</li>

<li>
[[OPEN FILE command|OPEN filename]] with deferred update
</li>
</ul>

==Login processing==

The system manager is responsible for defining security processing in a Model 204 installation in which Security Server supplies authorization services. This section describes the login processing performed by the Security Server Interface. 

===Model 204 and Security Server login processing===

When a user logs in to Model 204, Model 204 acquires the user ID and account and searches CCASTAT to determine whether or not the user ID exists.
If the user ID is found, Model 204 queries the user for a password and proceeds with authorization processing. If the RACFPARM module indicates that CCASTAT defined users cannot log in, the login fails.
If the user ID is not found in CCASTAT and Security Server security is in effect, Model 204 uses Security Server facilities to authorize the user login: 

<ul>
<li>Model 204 passes the login user ID and password to Security Server to verify that the user is a valid Security Server user and that the password is correct.
</li>

<li>If the site has chosen to verify that the user is authorized to use Model 204, Security Server is asked if the user has PERMIT
authority to access the generic profile for resource group.LOGIN. If this check is successful, account processing occurs.
</li>

<li>If the installation has chosen to verify the account, the value entered is checked against the Security Server profile for
comgroup.ACCOUNT.account. If the value entered has PERMIT authority, the user is allowed into Model 204.
</li>
</ul>

If Security Server denies system access because of an invalid password or account, or if the user is not authorized to use Model 204, no login occurs and Model 204 issues an error message. 

Once users are successfully logged in, they are granted Model 204 privileges of X‘00’. Any additional privileges are determined whenever they enter a Model 204 command that requires a specific privilege. 

Users who do not log in directly to Security Server are automatically restricted in what they can do by the privileges associated with the default user ID. Refer to [[#Security Server default user ID|Security Server default user ID]] for more information.

All the system manager commands concerning CCASTAT maintenance functions work as usual. The ZBLDTAB and ZCTLTAB utilities also continue to work as usual. 

File, group, and subsystem security functions are defined as described in the Model 204 documentation, particularly the [[Security]] wiki topic. 

===User 0 login===

When the Security Server Interface is active, User 0 is validated as the owner of the Model 204 run, regardless of whether the
run is Online, BATCH204, IFAM1, or IFAM4. Model 204 always attempts to log in User 0 automatically, and verifies that any user ID supplied matches the user ID of the owner of the address space. It is not necessary to supply a user ID on the login command for User 0; Model 204 determines the owner user ID and supplies it automatically. 

If a user ID is supplied on the login command and the user ID does not exist on CCASTAT, it must match the user ID of the owner of the address space or the login fails. If the user ID is found on CCASTAT and CCASTAT users are allowed to log in, all further authorization checking is based on a default user ID specified by the installation (if running as an APF-authorized program). 

BATCH204 and IFAM4 can run without APF authorization if the user ID is equal to the ADDR SPACE ID and there is no default login ID (you cannot login from CCASTAT). If you try to log in without meeting these conditions, your login fails or a B78 System ABEND occurs. 

Technical Support recommends that you do not specify a user ID in the login for User 0, so jobs can be easily migrated from test to production without having to change the login command. 

Whether or not you supply a user ID, no password is needed and Model 204 does not prompt for one. If a password statement is coded in the input stream, it is treated as an invalid Model 204 command. If the user ID is on CCASTAT, Model 204 prompts for a password. If the password is correct, the login succeeds but all future data set authorization checking is based on the default user ID. 

===AUTHCTL VIEW command===

The AUTHCTL VIEW command displays the interface control options currently in effect for the active interface.


For example, if you enter: 

AUTHCTL VIEW 
or
AUTHCTL VIEW RACF

The following list is displayed (assuming this information was used during initialization): 

Security Server INTERFACE OPTIONS
GROUP M204TEST <var class="term">Security Server control group name</var>
COMGROUP M204COM <var class="term">Security Server common control group name</var>
VALIDATE LOGIN <var class="term">Validation option in effect</var>
VALIDATE ACCOUNT <var class="term">Validation option in effect</var>
PRIORITY LOW <var class="term">Priority default</var>
DLMCHECK <var class="term">Use $JOB DLM checking option</var>
M204GRP <var class="term">Default user group</var>
M204USR <var class="term">Default user ID</var>


The additional lines displayed indicate the current default user ID and group in use. For more information about defaults, refer to [[#Security Server default user ID|Security Server default user ID]].


For information about setting control information, see [[#Preparing a RACFPARM parameter module with RACFGEN|Preparing a RACFPARM parameter module with RACFGEN]]. 

===Using trusted login for CRAM users===

If your site uses CRAM, you can use the trusted login feature, which allows users to issue login commands or calls that do not include a user ID and password.
For a user to log in as trusted, the user ID must be defined to Security Server. User IDs defined to CCASTAT are not allowed to log in as trusted users. CICS users must be using the Security Server interface for CICS. Only CICS user IDs that log in through Security Server can log in as trusted users. 

Trusted login can be used with the following CRAM thread IODEV types: 

<ul>
<li>IODEV11 (CRFSCHNL)
</li>

<li>IODEV29 (CRIOCHNL)
</li>

<li>IODEV23 (IFAMCHNL)
</li>
</ul>

To set up trusted login for a user, set the SECTRLOG user parameter, as discussed in [[#Setting up the SECTRLOG parameter for trusted login|Setting up the SECTRLOG parameter for trusted login]]. 

====Login processing for trusted login====

For users connecting with a CRAM thread that allows trusted login, the user login processing routines are changed to handle a LOGIN command or IFSTRT call without a user ID and password: 
<ul>
<li>CRFS and CRIO channel threads handle User Language statements. These users ordinarily issue a LOGIN or LOGON request with the following format: 

LOGIN userid [account];password [:new password];apsyname


For trusted logins, the format is: 

LOGIN;;apsyname
</li>

<li>The IFAM channel threads handle IFAM2 statements. These users ordinarily issue an IFSTRT or IFSTRTN call with the following format: 

IFSTRT (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID) 

IFSTRTN (RETCODE,LANG_IND,LOGIN,THRD_TYP,THRD_ID,CHAN) 

The LOGIN parameter is required and supplies the user ID and password as a character string using the following format: 

‘userid [account];password [:new password];’


For trusted logins, the statement format is the same but the login character string is a semicolon surrounded by single quotes (';'). 
</li>
</ul>

====Trusted login errors====

When using trusted login, you might receive one of the errors described in this section. 
<ul>
<li>The following message: 
M204.2378: SECURITY TRUSTED LOGIN FEATURE DISABLED 
is generated in either of the following situations: 
<ul>
<li>The Model 204 job requesting the trusted login feature is running without a Model 204 Security Interface (CA-ACF2, Security Server, or CA-Top Secret).</li>
<li>
Model 204 address space does not have enough storage to allocate an internal work area for the trusted login feature. In this
situation, the Model204 job does not initialize because it still has to allocate storage for the Model 204 file buffers.
</li>
</ul>
</li>

<li>The following message is issued when the trusted user ID passed by CRAM is not between 1-8 bytes long:
M204.2379: INVALID TRUSTED USERID LENGTH = length
</li>
</ul>

==Maintaining the Security Server Interface==

At each Security Server site, the security administrator performs system-wide maintenance functions within Security Server. The security administrator is responsible for defining and maintaining the Security Server generic profiles and permits for authorization that are eventually used by Model 204. The following discussions describe the Model 204 data maintained by the security administrator. 

The privilege names that Model 204 uses are based on generic data set profiles. Although the Security Server ADDSD command describes a resource profile for Model 204, use it as if you are defining a data set. 

This method provides the simplest way to describe resources. You do not need to reassemble any Security Server modules because all definition is external. In addition, it is portable across Security Server releases, because no internal modifications are made to Security Server tables and no Security Server exits are used. 

In the following examples, the simplest set of conditions is described. You can fully utilize all Security Server options (for example, auditing when a resource is used, changing the universal access authority, or naming a specific owner of the group). Use security access levels for both the profiles and the permits for authorized users of those profiles. 

The interface requires that users of these resources are permitted READ authority. 

===Defining user privileges===

You must identify user privilege names as Security Server generic data set profiles. The standard Model 204 user privileges
described earlier have been assigned fixed names. The following set of user privilege names defines the possible privilege types for a user. These names are further qualified by the control group name entered in the RACFPARM module. 


These user privilege profile names are described in the following table. See the [[LOGCTL_command:_Modifying_user_ID_entries_in_the_password_table|LOGCTL]] command page for more information on the LOGCTL settings.


<table>
<caption>User privilege names</caption>

<tr>
<th>User privilege name... </th>

<th>Defines a user who can... </th>

<th>Corresponding LOGCTL setting </th>
</tr>

<tr>
<td>‘group.PRIV.SUPER.USER’ </td>

<td>Exercise superuser privileges: a user with READ access to this profile can execute a CREATE command. </td>

<td>X’80’ </td>
</tr>

<tr>
<td>‘group.PRIV.SYSTEM.ADMIN’ </td>

<td>Exercise system administrator privileges: a user with read access to this profile can issue system administrator commands such as LOGWHO, MONITOR, PRIORITY, and WARN. </td>

<td>X’40’ </td>
</tr>

<tr>
<td>‘group.PRIV.CHANGE.FILE .PASSWORD’ </td>

<td>Change the file password that is used to open a file: valid only if the file entry is stored in CCASTAT. </td>

<td>X’20’ </td>
</tr>

<tr>
<td>‘group.PRIV.SYSTEM .MANAGER’ </td>

<td>With system manager privileges: a user with read access to this profile can issue all system administrator commands along with certain other privileged commands such as LOGCTL, AUTHCTL VIEW, and DUMPG. </td>

<td>X’08’ </td>
</tr>

<tr>
<td>‘group.PRIV.OVERRIDE .RECORD.SECURITY’ </td>

<td>Override record security. </td>

<td>X‘04’ </td>
</tr>
</table>

===Defining corresponding generic profiles===

Security Server generic data set profiles must be developed and defined to Security Server to correspond to the defined
privileges. The Security Server generic data set profiles used to define the standard Model 204 privileges and other resources to
Security Server in a batch TSO execution are as follows: 

<nowiki>//JOBNAME JOB (other information).....
//DOIT EXEC PGM=IKJEFT01,DYNAMNBR=20
//SYSTSPRT DD SYSOUT=A
//SYSTSIN DD * </nowiki>
ADDGROUP group DATA('MODEL204 Security Server CONTROL GROUP NAME')
ADDSD 'group.PRIV.SUPER.USER*' UACC(NONE) GENERIC
ADDSD 'group.PRIV.SYSTEM.ADMIN*' UACC(NONE) GENERIC
ADDSD 'group.PRIV.CHANGE.FILE.PASSWORD.*' UACC(NONE) GENERIC
ADDSD 'group.PRIV.SYSTEM.MANAGER*' UACC(NONE) GENERIC
ADDSD 'group.PRIV.OVERRIDE.RECORD.SECURITY.*' UACC(NONE) GENERIC
ADDSD 'group.LOGIN*' UACC(NONE) GENERIC

ADDGROUP comgroup DATA('MODEL204 Security Server COMMON GROUP NAME')
ADDSD 'comgroup.SUBMIT*' UACC(NONE) GENERIC
ADDSD 'comgroup.PRIORITY.HIGH*' UACC(NONE) GENERIC
ADDSD 'comgroup.PRIORITY.STANDARD.*' UACC(NONE) GENERIC
ADDSD 'comgroup.PRIORITY.LOW*' UACC(NONE) GENERIC
ADDSD 'comgroup.ACCOUNT.<var class="term">nnnnnnnn</var>.*' UACC(NONE) GENERIC


Note: <var class="term">nnnnnnnn</var> represents an account number; there are as many as required. Also, high-level qualifiers cannot exceed eight (8) characters. 

In the following two sample PERMIT statements, the first is for a system manager and the second is for login authorization to a
copy of Model 204: 

PERMIT 'group.PRIV.SYSTEM.MANAGER*' ACCESS(READ)
ID(user ID1,user ID2.....)
PERMIT 'group.LOGIN*' ACCESS(READ)
ID(user ID1,user ID2.....)


where: 
<table class="noBorder">
<tr><td><var class="term">group</var>.PRIV.<var class="term">privilege</var></td> <td>Specifies one of the fixed types that Model 204 uses to build Security Server retrieval search keys for the rules </tr>

<tr><td><var class="term">group</var></td> <td>Is the Security Server control group defined to Model 204</td></tr>
</table>

The previous Security Server PERMIT statement sample permits the specified users to access the named resource. Rules for determining the authorized user are described in the [http://www-03.ibm.com/systems/z/os/zos/features/racf/library/library.html IBM Security Server documentation].
The privilege rules are tested whenever a user issues a command that requires a specific privilege. If the user is authorized to have that privilege, the command succeeds. If not, the user typically receives a Model 204 error message and the attempt might be logged as an Security Server violation. 

==Installing the Security Server Interface==

The Model 204 interface to Security Server consists of the following components: 

<ul>
<li>Code in Model 204 that utilizes Security Server facilities
</li>

<li>Security Server group and generic data set profile definitions defined at your site
</li>

<li>SECPLIST User 0 parameter in CCAIN
</li>
</ul>

The user site requirements that must be met in order to activate the Security Server Interface are identified in this section. 

===Terminal security considerations===

Security Server can enforce terminal security when a user logs in. At that time, the source of the login is passed to Security
Server. For systems running Model 204 with the SNA Communications Server (formerly VTAM) interface, this poses no problem
because Model 204 recognizes the terminal name and stores it for use. 

Configurations using CRAM (TSFS, CICS, IFDIAL) must use the CRAM channel name instead of the terminal ID as the user
source, because there is no secured mechanism in CRAM for identifying the source of the user. Because CRAM channel names
can be identified as valid sources, the user IDs allowed to use those sources can be validated. Using the CRAM channel name
temporarily ensures that entry to Model 204 is from an approved source. 

===Decrypting Security Server===

As part of INS204, the M204DECR job is generated with all the steps needed to decrypt Security Server.
Refer to the <var class="book">[http://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew556/model%20204/v7.4/m204_v7r4_zos_install_guide.pdf Rocket Model 204 Installation Guide for IBM z/OS]</var> for more information. 

===SECPLIST parameter===

The SECPLIST User 0 parameter in CCAIN lets you specify the name of the RACFGEN argument set with which to initialize the interface. The name is defined by the assembler label name of the RACFGEN macro. 
<ul>
<li>If the SECPLIST parameter is not in CCAIN, RACFPARM is used as the default name of the argument set.
</li>

<li>If no match is found for the SECPLIST name or the RACFPARM default name in the RACFPARM module, the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed. </li>
</ul>

The following RACFPARM module contains two sets of Security Server arguments:
<ul>
<li>In the first set, the name is LOG1 and account security is in effect. If the user is logged on through CCASTAT, the default Logonid is M204USER.</li>
<li>In the second set, the name is LOG2 and both account and login security are in effect. In addition, if the user is logged on through CCASTAT, the Logonid of the executing job is considered the default Logonid.</li>
</ul>

 TITLE 'RACFPARM MODULE' X
LOG1 RACFGEN GROUP=M204PROD, X
COMGRUP=M204RACF, X
PRTY=H, X
VALIDAT=ACCOUNT, X
DEFUSER=M204USER, X
DEFGRP=, X
DEFPASS=, X
DMLCHECK
LOG2 RACFGEN GROUP=M204TEST, X
COMGRUP=M204RACF, X
PRTY=S, X
VALIDAT=(ACCOUNT,LOGIN), X
DEFUSER=JOBNAME, X
DEFGRP=M204GRP, X
DEFPASS=DEFPASS, X
DMLCHECK
RACFGEN TYPE=END
END


===Preparing a RACFPARM parameter module with RACFGEN===

The RACFGEN macro generates a set of arguments that govern login and other security processes. There can be multiple
argument sets in a RACFPARM module. The RACFPARM parameter module can be linked with Model 204 or dynamically loaded
when the Security Server Interface is initialized.

The arguments for the RACFGEN macro are described in detail in this section. 

The following is a sample RACFGEN macro with one set of arguments. The name of the argument set is RACFPARM, which is
the required name if you are linking statically into your Model 204 modules. 

TITLE 'GENERATE A Security Server PARAMETER MODULE'

RACFPARM RACFGEN GROUP=M204RACF, Control group X
COMGRUP=M204RACF, Common control group X
PRTY=S, Priority X
VALIDAT=, Validation items X
DEFUSER=M204USR, Default user ID X
DEFUGRP=M204GRP, Default user group X
DEFPASS=M204PASS, Default user password X
DLMCHECK/NODLMCHECK Check DLM=
RACFGEN TYPE=END
END


where: 
<ul>
<li>RACFPARM defines the name of this set of Security Server arguments. Because there can be any number of argument
sets in the RACFPARM module, each set must be given a unique name. There is no default name.

Note: If you want to statically link the RACFPARM module, you must include (as the first argument) a Security Server argument set named RACFPARM. Otherwise, the SECPLST value for the user is not found in the RACFPARM module, and the interface is initialized using the precoded default parameters defined in the Security Server Interface. In this case, Login, Account, and Priority validation are not performed. This may result in the user being unable to login. 
</li>

<li>GROUP specifies the 1- to 8-character Security Server control group name selected by your site. The rules for Model 204 privileges are defined and grouped by this code and stored in Security Server profiles. The group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of <var class="term">group.keyword.variable.data</var>.

The default is M204RACF. 

You can use the <code>GROUP</code> name to create a separate set of privilege definitions for an individual copy of Model 204. This allows
your site to have different privileges for different versions of Model 204, for instance for test and production. </li>

<li>COMGRUP specifies the 1- to 8-character Security Server common group name selected by your site. The rules for the VALIDAT ACCOUNT, PRIORITY, and SUBMIT options are defined and grouped by this code and stored in Security Server profiles.

The common group name must match the generic profile high-level qualifier defined to Security Server in the ADDSD statements for the profiles, all of which take the form of <var class="term">comgroup.keyword.variable.data</var>. 

The default is <var>M204RACF</var>, if a group name is not specified. 

Note: COMGRUP is used to create a common set of privilege definitions shared between copies of Model 204. 
</li>

<li>PRTY specifies the default priority for any user who successfully logs in through Security Server. Options are H (high), S (standard), L (low), or N (none). The default priority is STANDARD if the PRTY keyword is omitted. For more information about priorities, refer to [[Controlling system operations (CCAIN)#Priority scheduling|Priority scheduling]].
</li>

<li>VALIDAT specifies the type of validation to be performed. Multiple validation types can be specified for the interface.

Options are: 

<ul>
<li>ACCOUNT specifies that Security Server validates any account entered by the user during the login process. VALIDAT ACCOUNT verifies that Security Server permits the account value entered by the user. If so, the user is allowed in to Model 204. If not, the login fails.

This validation uses the comgroup.ACCOUNT.account# profile.
</li>

<li>LOGIN specifies that Security Server rules are tested to determine if a user is allowed to log in to Model 204. If VALIDAT LOGIN is specified, the Security Server Interface determines if the user is permitted to use Model 204 before allowing access. If LOGIN is not specified, all users who pass the user ID/password and optional account validation are allowed access to Model 204.

This validation is performed using the profile group.LOGIN, so it can be used to limit the ability to log in when several copies of Model 204 are running. </li>

<li>PRIORITY verifies which priority the user is permitted to have. This option can be specified in addition to a standard priority. If priority validation fails, the standard priority is the default.

This validation uses the profiles:
comgroup.PRIORITY.HIGH
comgroup.PRIORITY.STANDARD
comgroup.PRIORITY.LOW
comgroup.PRIORITY.NONE

Validation is checked from highest to lowest priority. If a user has PERMIT access to one of these priorities, the value is assigned. If no PERMIT is found and a standard priority is not specified, the priority for the user is set to STANDARD. 
</li>

<li>SUBMIT uses Security Server rules to determine whether or not a user is allowed to issue the USE command to submit a job through the internal reader. If this option is specified, Security Server checks the user’s authorization privileges before allowing the user to submit the job. If this option is not specified, all users who pass the user ID/password and optional account validation are allowed to submit jobs. 

This validation uses the comgroup.SUBMIT profile. 
</li>
</ul>

<li>DEFUSER defines the default submitting user’s Security Server user ID if the user is not directly logged in through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server user ID is used when submitting jobs.

<ul>
<li>If DEFUSER=, that is, this field is left blank, then CCASTAT-defined users are not allowed to log into Model 204. Only valid Security Server users can utilize the running system.
</li>

<li>If DEFUSER=<var class="term">JOBNAME</var>, then the following occurs. The ASID ACEE is moved to DEFUSER, the GROUP ACEE is moved to
DEFGROUP, and the default user’s ACEE pointer is set to AUCKDPTR.
</li>
</ul>

<li>DEFUGRP defines the default Security Server group to which a submitting user is assigned if the user is not directly logged in
through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server group is used when submitting jobs.
</li>

<li>DEFPASS defines the default PASSWORD for the default user ID if the user is not directly logged in through Security Server. Refer to [[#Job submission considerations|Job submission considerations]] for a description of how the Security Server password is used when submitting jobs.
</li>

<li>The DLMCHECK/NODLMCHECK argument specifies DLM processing options for jobs submitted through the internal reader using the USE command. The DLM parameter on a DD * or DD DATA statement allows a job to be submitted that can itself submit other jobs. This is a potential security compromise. The DLMCHECK/NODLMCHECK argument provides the ability to enforce certain rules when coding the DLM= parameter.

DLM processing options are as follows: 
<ul>
<li>DLMCHECK enforces the rule that if a DLM= parameter is used in a JCL stream, it must be the only parameter supplied. In this case, only the following forms of these statements are correct:

//DDNAME DD *,DLM=';;' 

or 

//DDNAME DD DATA,DLM='&&&&' 

In these statements, the DLM value follows the rules described in [http://www.ibm.com IBM] JCL documentation; any other parameters supplied result in an error. If there is a job statement following the offending statement, Model 204 appends the following to the job statement set as if it is an independent job: 

USER=...,PASSWORD=...GROUP=... 
</li>

<li>NODLMCHECK checks only the validity of the DLM= parameter and not the other optional parameters that can be specified on the JCL statement. All JCL statements after the DLM= parameter are sent to the internal reader without being checked. This argument does not guarantee that an error on the statement with the DLM= parameter is caught before it is submitted.

DLMCHECK is the default. 
</li>
</ul>
</li>
</ul>

The result from assembling the RACFGEN macro is link-edited to a library that is included in a Model 204 link-edit, or it can be optionally linked into a separate library and loaded at execution time. 

If you link RACFPARM as a separate load module, use the SECRLINK job in the JCL library. Modify the job according to the comments. 

If you link RACFPARM with the Model 204 configuration, add the following line in SYSLIN for the link-edit steps of ONLINE, BATCH204, IFAM1, and IFAM4. 

INCLUDE OBJLIB(RACFPARM) 

===Model 204 link-editing requirements===

To support multiple Model 204 logins for different user IDs, Model 204 must be linked to an authorized library using the
appropriate Security Server services. This means that any Online configuration must be linked to an authorized library. 

BATCH204 or IFAM can be linked to a nonauthorized library, provided that the user logging in is the same user who starts the job and there is not a default login ID that prevents CCASTAT logins. Otherwise, the login fails or a System B7A ABEND occurs. 

===Defining Model 204 to Security Server===

Model 204 allows multiple users per address space and provides services to many users through its own processing, but Security Server is aware only of the maintask in the address space (in this instance, Model 204). Model 204 must be defined as having the appropriate Security Server privileges to perform services on behalf of a Model 204 control group. 

You can define an additional Security Server control group for nonshared resources as well as for resources shared between
multiple copies of Model 204.The first step in the definition process is to choose a name and define a profile for the Model 204
control group and optionally the common group. For example: 

ADDGROUP M204RACF OWNER(SECURITY) DATA('MODEL 204 CONTROL GROUP')
ADDGROUP M204COM OWNER(SECURITY) DATA('MODEL 204 COMMON CONTROL GROUP')


===Defining Model 204 users in Security Server===

In Security Server, the user profile record contains all information for a defined user of a computer system. There are no special entries or any differences in the way a Security Server user is defined to the system. All authorization services are performed using the generic profiles for privileges. See [[#Defining corresponding generic profiles|Defining corresponding generic profiles]] for more information.


===Security Server default user ID===

The default user ID limits the authorization of users that have not logged in directly to Security Server (that is, users still defined in CCASTAT). 

Each user not logged directly into Security Server is assigned the authorization provided by Security Server for the default user ID. The authorization includes all user resource requests, as described in [[#Running the Security Server Interface with Model 204|Running the Security Server Interface with Model 204]].

The default user ID automatically is assigned the user ID M204USR with the password M204PASS and belongs to group
M204GRP. A user ID of this name must be defined to Security Server for CCASTAT-defined users to be able to log in. 

For security reasons, the system manager cannot modify this group, user ID, and password. If different data is required or if the installation would like to change defaults, the parameter module RACFPARM must be modified by the Security Server security
administrator or systems programmer. 

RACFPARM provides the mechanism to supply overrides to the default group, user ID, and password. This module can be made available during the Model 204 link-edit. Otherwise, Model 204 attempts to load it at the time the interface is initialized. If the module is loaded dynamically, it must be made available in the STEPLIB containing Model 204 or in a system load library. The RACFPARM module is generated with the RACFGEN macro. 

Note: All LOADLIBs concatenated in one STEPLIB must be APF-authorized or you lose your APF authorization for that job step. 

===Setting up the SECTRLOG parameter for trusted login===

The SECTRLOG user parameter defines which CRAM thread applications are allowed to log in to Model 204 with a trusted user ID. The CRAM threads for which trusted login applications are allowed are: 

<ul>
<li>
IODEV11 (CRFSCHNL)
</li>

<li>
IODEV29 (CRIOCHNL)
</li>

<li>
IODEV23 (IFAMCHNL)
</li>
</ul>

SECTRLOG must be set on the first IODEV line for each trusted CRAM thread, because it is picked up during the initialization of each CRAM channel.
The following settings are valid: 

<table>
<tr>
<th>Setting</th> <th>Meaning</th></tr>

<tr><td>X'00'</td> <td>Trusted Login not allowed (default)</td> </tr>

<tr><td>X'01'</td> <td>CICS applications (CRFS, CRIO, IFAM)</td> </tr>

<tr><td>X'02'</td> <td>TSO applications (CRIO, CRFS)</td> </tr>

<tr><td>X'04'</td> <td>Batch applications (CRIO, IFAM)</td> </tr>
</table>

===Conversion tasks and considerations===


The following table identifies the general tasks that must be completed to install and activate the Security Server Interface. Before conversion, you also might want to review the RACFPARM module definitions and link a separate copy of Model 204 for testing and production. 

Conversion checklist for Security Server 
<table>
<tr><th>Step</th> <th>Task</th></tr>

<tr><td>1.</td> <td>Define a Security Server GROUP control profile for Model 204.</td>
</tr>

<tr><td>2.</td> <td>Define a Security Server GROUP common profile for Model 204. </td>
</tr>

<tr><td>3.</td> <td>Define Security Server generic profiles for user privileges, and specify the users who have PERMIT access to have those privileges. </td>
</tr>

<tr><td>4.</td> <td>Define Security Server generic profiles for:
<ul>
<li>Model 204 login authority related to the control group if the VALIDAT LOGIN option is specified in the RACFPARM</li>

<li>Authorized account code profiles related to the common group if the VALIDAT ACCOUNT option is specified in the RACFPARM</li>

<li>Authorized PRIORITY profiles if the VALIDAT PRIORITY option is specified to assign individual priorities to users and specify which users have PERMIT access for those privileges</li>
</ul></td>
</tr>

<tr><td>5.</td> <td>Run RACFGEN to assemble the RACFPARM module.</td>
</tr>

<tr><td>6.</td> <td>Link RACFOS into Model 204.</td>
</tr>

<tr><td>7.</td> <td>Link RACFPARM$ into Model 204 directly or use SECRLINK to create a separate LOAD module to be used for dynamic linking at initialization.</td>
</tr>

<tr><td>8.</td> <td>Add a new parameter in the user zero input stream called SECPLIST=<var class="term">parametername</var>. </td>
</tr>

<tr><td>9.</td> <td>Delete Model 204 users from CCASTAT to turn on Security Server authorization checking.</td>
</tr>
</table>

[[Category:Security interfaces]]

Release notes for Model 204 version 7.5

2015-01-02T21:08:13Z

Teagan:

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

==Overview==
These release notes describe features and system requirements for Rocket Model 204 version 7.5. Read through this information before beginning your 7.5 installation.

==New in this release==
This section summarizes the new features and enhancements for Model 204 version 7.5.

===SOUL (User Language)===
The significantly enhanced, object-oriented, version of User Language is now called [[#SOUL (User Language) enhancements|SOUL]]. All existing User Language programs will continue to work under SOUL, so User Language can be considered to be a subset of SOUL, though the name "User Language" is now deprecated.
<ul>
<li>integration of [[#Object-oriented programming|object-oriented language extensions]] from the Janus SOAP User Language Interface</li>
<li>[[Release notes for Model 204 version 7.5 (DRAFT)#External Call Facility .28ECF.29|ECF]] CALL statements can pass up to 60 parameters</li>
</ul>

===System management===
<ul>
<li>[[#Writing records to the SMF data set|Writing records to the SMF data set]] without an SVC installed</li>
</ul>

===Performance===
GTBL, NTBL, and QTBL can be stored [[#64-bit addressing and Above The Bar (ATB) storage|above the bar]]
===Application flexibility===
[[Release notes for Model 204 version 7.5 (DRAFT)#Support for physical field groups|Support for physical field groups]]

==Operating system support and requirements==

<ul>
<li>IBM z/OS
<ul>
<li>Latest version supported: z/OS Version 2 Release 1.</li>
<li>Version required: z/OS Version 1 Release 7 or later.</li>
V1R7 is sufficient for all new functionality except for the following
features:
<ul>
<li>Large (1 MB) page support requires Version 1 Release 9.
<li>Extended address volumes (EAV) requires Version 1 Release 12.
</ul></li>
</ul>
Authorization under APF is required to run Model 204 V750 under any z/OS operating system.

<li>IBM z/VM
<ul>
<li>Latest version supported: z/VM version 6 Release 3. </li>
<li>Version required: z/VM version 5 Release 4.0 or later.
</ul>
<li>IBM z/VSE
<ul>
<li>Latest version supported: z/VSE Version 5 Release 2.
<li>Version required:
<ul>
<li>Version 5 Release 2 or
<li>Version 5 Release 1
</ul>
</ul>

</ul>

=== Hardware requirements ===

Model 204 version 7.4 requires the IBM z/890 or above processor, except for the following feature:

The large (1 MB) page support feature requires the IBM z10 or above processor. 

===Model 204 compatibility with operating systems===

For information on Model 204 certification with IBM operating systems, see:
http://www.rocketsoftware.com/products/rocket-model-204/technical-information

<div id="Connect* compatibility with Model 204"></div>
===Connect★ compatibility with Model 204===
Connect★ version 7.5 is compatible with all versions of Model 204.

===Upgrading requirements===
Model 204 version 7.4 is required to [[#Upgrading instructions for version 7.5|upgrade]] to Model 204 version 7.5.

==SOUL (User Language) enhancements==
Much of the substantial new and enhanced functionality described in the following subsections is available as a result of the acquisition of Sirius Software. The functionality that is the subject of the initial subsection, "Object-oriented programming," motivates the new name for User Language, '''SOUL''' (Simple Objective User Language).

===Object-oriented programming===
As of version 7.5 of Model 204 (and backward compatible with existing User Language applications), the SOUL language is equipped with [http://en.wikipedia.org/wiki/Object-oriented Object-Oriented Programming](sometimes abbreviated OO) capabilities comparable or superior to other contemporary object-oriented languages. The OO features were formerly contained in the [[Janus SOAP User Language Interface]], and you can use [[Object oriented programming in SOUL]] as an entry point to the extensive SOUL OO documentation. In particular, you might want to begin with the [[Getting started with OOP for User Language programmers|OOP tutorial]].

===Record capacity increase===
In this version of Model 204, the record limit is increased from sixteen million records to forty-eight million records per file.

===New SOUL statements===
{{Template:User Language statements}}

===Non-OO enhancements in SOUL===
{{Template:User Language syntax enhancements}}

===SOUL support for field groups===

====ADD (or INSERT or DELETE) FIELDGROUP statements====
The <var>ADD FIELDGROUP</var> statement and the <var>INSERT FIELDGROUP</var> statement behavior parallels the behavior of the <var>ADD</var> and <var>INSERT</var> statements for simple fields. The <var>DELETE FIELDGROUP</var> statement handles more situations and is therefore more complex.
See [[Data maintenance#Updating field groups|Updating field groups]] for details.

====Statements for handling field groups====
SOUL now provides several statements for handling field groups:
<ul>
<li><var>FOR FIELDGROUP</var></li>
<li><var>FOR ALL OCCURRENCES OF FIELDGROUP (FAO FIELDGROUP)</var></li>
<li><var>FOR EACH OCCURRENCE OF FIELDGROUP (FEO FIELDGROUP)</var></li>
</ul>

See [[Processing multiply occurring fields and field groups#Working with field groups|Working with field groups]] for details.

====Output statements for field groups====

The following SOUL statements provide display output for Model 204 field groups:
AUDIT ALL FIELDGROUP INFORMATION (AAFGI)
PRINT ALL FIELDGROUP INFORMATION (PAFGI)


See [[Basic SOUL statements and commands#Output statements for fields and field groups|Output statements for fields and field groups]] for details.

====Field group SORT support====
You can now use field groups in [[Sorting#Field group SORT support|sorted sets]]. <var>SORT</var> statement support for field groups lets you sort records with field groups as well as reference field groups in the sorted sets. For example, you can issue a <code>FAO FIELDGROUP</code> statement or <code>FEO FIELDGROUP</code> statement against the sorted set.

===EQ VALUE retrieval condition===

SOUL now provides the <var>EQ VALUE</var> clause to support expressions in <var>FIND</var> statements.

See [[Record retrievals#Using expressions in FIND statements|Using expressions in FIND statements]] for details.

===EQ WITH retrieval condition for concatenated fields===
SOUL now provides the <var>EQ WITH</var> clause for retrieving <var>CONCATENATION-OF</var> fields. Model 204 automatically builds the concatenated value.

See [[Record retrievals#Using expressions in FIND statements|Using expressions in FIND statements]] and [[Record retrievals#EQ WITH retrieval condition for concatenated fields|EQ with retrieval condition for concatenated fields]] for details.

===External Call Facility (ECF)===
<var>EXTERNAL CALL</var> statements can now pass more parameters.
The maximum number of parameters that can be passed in an <var>EXTERNAL CALL</var> statement has been increased from 40 to 60.
The maximum value setting for <var>[[ECPSIZE parameter|ECPSIZE]]</var> is increased from 1310680 to 1966020 to accommodate the extra parameters.

ECF is available only on z/OS systems. For more information about the External Call Facility and the <var>EXTERNAL CALL</var> statement, see the [[External Call Facility]] topic.

===REPEAT statement UNTIL option===
The <var>REPEAT</var> statement now supports the <var>UNTIL</var> option. In previous releases, only <var>REPEAT WHILE</var> was supported.

A <var>[[Flow of control in User Language#REPEAT UNTIL statement|REPEAT UNTIL]]</var> statement enters the loop body prior to checking the condition.

===New and changed classes and methods===

====New InvalidBitNumber class====
Objects of the [[InvalidBitNumber class|InvalidBitNumber exception class]] are thrown when an invalid bit number is requested by a bit manipulation function. It is currently thrown only by the <var>[[BitClearString (String function)|BitClearString]]</var>, <var>[[BitFlipString (String function)|BitFlipString]]</var>, <var>[[BitSetString (String function)|BitSetString]]</var>, and <var>[[BitValueString (String function)|BitValueString]]</var> functions.

====New InvalidTranslateTable class====
Objects of the [[InvalidTranslateTable class|InvalidTranslateTable exception class]] are thrown when a requested system translate table cannot be found. It is currently thrown only by the <var>[[TranslateTable (HttpRequest property)|TranslateTable]]</var> <var>HttpRequest</var> property.

====New bit manipulation String functions====
New bit manipulation functions <var>[[BitClearString (String function)|BitClearString]]</var>, <var>[[BitCountString (String function)|BitCountString]]</var>, <var>[[BitFlipString (String function)|BitFlipString]]</var>, <var>[[BitSetString (String function)|BitSetString]]</var>, and <var>[[BitValueString (String function)|BitValueString]]</var> make it easier to manipulate the bits in a string.

====New String processing functions====
New <var>String</var> functions <var>[[Before (String function)|Before]]</var> and <var>[[After (String function)|After]]</var> return the parts of a string before or after a user-specified delimiter string.

====New Stringlist subroutine====
New <var>Stringlist</var> subroutine <var>[[AppendPemData (Stringlist subroutine)|AppendPemData]]</var>
appends a PEM encode string to a <var>Stringlist</var>.

====New System methods TODClock and UUIDTime====
New System class methods [[TODClock (System function)|TODCLOCK]] and [[UUIDTime (System function)|UUIDTime]] have been created to facilitate generation of version 1 universal unique identifiers and to provide high precision time stamps for SOUL applications. These methods were actually added as a ZAP update to Model 204 7.5 (75Z109).

====New HttpRequest TranslateTable property====
The <var>[[TranslateTable (HttpRequest property)|TranslateTable]]</var> <var>HttpRequest</var> property makes it possible to set the translate table to be used for EBCDIC to ASCII translation of data in an <var>HttpRequest</var> object.

====Disable base64 encoding in LoadFromRecord and related methods====
The <var>Base64Encode</var>=<var>False</var> argument can be used with the <var>[[LoadFromRecord (XmlDoc/XmlNode subroutine)|LoadFromRecord]]</var> method to disable any base64 encoding of field values.

Alternatively, the <var>CharacterMap</var> argument (with a non-null value) can be used to disable any base64 encoding of field values, and to specify translations, which can avoid request translation due to X'00' and/or untranslatable characters in field values.

These arguments are also added to the <var>[[NewFromRecord (XmlDoc function)|NewFromRecord]]</var> and <var>[[ToXmlDoc (Record function)|ToXmlDoc]]</var> methods.

====New parameter for AppendJournalData====
The <var>QT</var> option is added to the <var>[[AppendJournalData (Stringlist function)#Options parameter|AppendJournalData]]</var> method, to include QT type audit entries.

====New parameter for AddField====
The <var>Strip</var> option is added to the <var>Screen</var> class method <var>[[AddField (Screen function)|AddField]]</var> to allow suppression of leading and trailing blank removal from input fields.

===New and changed $functions===

====Former Sirius $functions====
The $functions referred to by the link below are added to SOUL as a result of the acquisition of Sirius Software:
:[[List of $functions|Sirius $functions]]
Among these $functions are integrated [[List_of_mathematical_$functions|math $functions]]: high-performance, high-precision versions of the IBM mathematical functions. These functions eliminate the need to use external math libraries.

====$SndMail attachment ASCII translation====
The <var>[[SOUL_$functions#Sending_email_messages_via_$Sndmail|$SndMail]]</var> function can now translate an attachment to ASCII before sending it.
This translation is useful if the <var>$SndMail</var> attachment is a <var>CLOB</var> (<var>CHARACTER-LARGE-OBJECT</var>) such as a text document.

The <var>$SndMail</var> function now accepts an optional parameter after the name of the attached object. If this parameter is set to 'C' (or to a percent variable with the value 'C'), the object in the buffer is translated to ASCII before being attached to the email.

If this parameter is not specified, the object in the buffer is sent as a binary object.

In this example:
%RC = $SNDMAIL(%SUBJECT,,%BODY,%FROM,%TO,,,,'CLOB.TXT','C')

the <code>CLOB.TXT</code> attachment will be translated to ASCII before being attached to the email.

====New function calls for field groups====
When a field group is added, a [[Data maintenance#Updating field groups|field group ID]] is assigned to the field group.
<ul>
<li><var>[[$FieldgroupId]]</var> returns the ID of the current field group.</li>
<li><var>[[$FieldgroupOccurrence]]</var> returns the current occurrence number of the field group.</li>
</ul>

==Sirius products and product enhancements==
[[Sirius Software product list|The former-Sirius products]] are now available to Model 204 customers as separately purchased items as a result of the acquisition of Sirius Software.

===Changes to Janus SSL support===
Under Model 204 version 7.5, Janus products:

<ul>
<li>Drop version 2 of Secure Sockets Layer (SSL V2); add versions 1.1 and 1.2 of Transport Layer Security (TLS 1.1 and 1.2)

You can use the <var>[[SSLPROT (JANUS DEFINE parameter)|SSLPROT]]</var> parameter on the <var>JANUS DEFINE</var> command for a port to explicitly specify, or limit, the SSL/TLS protocols available for a connection. The <var>SSLPROT</var> documentation describes the SSL/TLS protocols that Janus supports. 

Janus support for SSL V2 also included an option to specify a larger than "legal" input buffer for connections not strictly conforming to the V2 standard. You specify that buffer size with the <var>JANUS DEFINE</var> <var>[[SSLIBSIZE (JANUS DEFINE parameter)|SSLIBSIZE]]</var> parameter, and the <var>SSLIBSIZE</var> maximum value as of Model 204 V7.5 is reduced (from 32767 bytes) to the SSL maximum allowed size of 16384. </li>

<li>Add support for new ciphers

You can use the <var>[[SSLCIPH (JANUS DEFINE parameter)|SSLCIPH]]</var> <var>JANUS DEFINE</var> parameter to specify the SSL ciphers available for a connection. <var>SSLCIPH</var> bits X'3F8' are all new in version 7.5 of <var class="product">Model 204</var>. </li>
</ul>

===WEBOPT parameter change===
The <var>[[WEBOPT parameter|WEBOPT]]</var> parameter default value is changed to X'03' from 0. <var>WEBOPT</var> affects the interaction of Model 204 and RACF security.

==File-related enhancements==
Note: These features are not supported in Dictionary/204 version 7.5.

===Support for physical field groups===
Model 204 supports non-relational, de-normalized data structures. Many Model 204 sites have enjoyed significant cost and performance benefits from efficiently processing multiply occurring fields. This concept has been enhanced to introduce physical field groups that let you view and process groups of fields as a logical entity.

You can define a physical field group only for files with the <var>[[#FILEORG (new settings)|FILEORG X'100']]</var> setting. To take advantage of field groups in files defined before Model 204 version 7.5, you must reorganize the files with a <var>FILEORG</var> setting that includes the X'100' bit.

Files with <var>FILEORG</var> X'100' can have up to 32,000 fields.

For more information, see [[Field group design]].

===Increased Table B record number capacity===
[[Table B (File architecture)|Table B]] can now contain up to 48M possible record numbers. (The previous limit was 16M.)

Set the [[#FILEORG (new settings)|FILEORG X'200' bit]] at file creation time to allow for the increased record numbers.
<blockquote class="note">
Notes: 
<ul>
<li>The limit for <var>BSIZE</var> remains at 16M.

<code>BSIZE * BRECPPG</code> must be less than or equal to 48M (actually decimal 50,331,648 to be exact). 

For example, if <var>BSIZE</var> is 16M, <var>BRECPPG</var> cannot be more than 3. </li>

<li>The <var>FILEORG</var> X'200' bit cannot be set for files with hash key or sorted file organization.</li>
</ul>
</blockquote>

===Automatic fields===
Model 204 now lets you define a field whose value is [[Field design#Automatic fields|automatically maintained]]. A field can count occurrences of another field so that every store or delete of the field occurrence changes the count in the automatic field. The following automatically maintained field attributes are available for files defined with the FILEORG x'100' setting:
<ul>
<li><var>COUNT-OCCURRENCES-OF</var></li>
<li><var>CREATE-TIME</var></li>
<li><var>CREATE-TIMEUTC</var></li>
<li><var>CREATE-USER</var></li>
<li><var>UPDATE-TIME</var></li>
<li><var>UPDATE-TIMEUTC</var></li>
<li><var>UPDATE-USER</var></li>
</ul>

The value of an automatic field is updated at the start of a transaction by Model 204 and you cannot set it explicitly by a program. Any valid update statement causes the appropriate time and user stamps to be updated. For example, the time and user stamps will be updated when <code>DELETE FOO(8)</code> is processed, even if there are no occurrences of FOO in the record and an actual update does not take place.

Once you define an automatic value for a field, you cannot redefine the automatic value.

===Concatenated fields===
Model 204 now lets you define [[Field design#Concatenated fields|concatenated fields]].

Fields that make up concatenated field values must be <var>AT-MOST-ONE</var>, <var>EXACTLY-ONE</var>, or <var>OCCURS</var> 1 and must all be in the same field group context (or not in a field group). Fields that occur in all field groups (<var>FIELDGROUP *</var>) cannot be used in a concatenation.

If a concatenated field becomes longer than 255 bytes after adding separator and escape characters, the update request is cancelled.

===New field attributes===
Model 204 version 7.5 introduces the new <var>[[DEFINE FIELD command|DEFINE FIELD]]</var> attributes described in this section. These attributes apply to all fields in Model 204. 

Note: These attributes all require that the <var>[[FILEORG parameter|FILEORG]]</var> parameter X'100' bit be set on the file containing the fields.

Changes in the new field attributes are detected during the redefinition of an existing field. When such a change is detected, the following messages might be issued:
M204.1260: [FIELD | FIELDGROUP] WAS PREVIOUSLY DEFINED WITH DIFFERENT ATTRIBUTES,
NEW [FIELD | FIELDGROUP] OPTIONS IGNORED

or
M204.2884: [FIELD WAS PREVIOUSLY DEFINED AS A FIELDGROUP | FIELDGROUP WAS PREVIOUSLY
DEFINED AS A FIELD], NEW DEFINITION IGNORED


The table below lists the new field attributes. For details on each attribute, click its name. For more information on how related attributes work together, see the [[Field design]] topic.
<table>
<tr class="head">
<th>Attribute</th><th>Abbreviation</th><th>Description</th>
</tr>

<tr>
<td>[[DEFINE_FIELD_command#Ordered_index_CHUNK_attribute|CHUNK]]</td>
<td>CNK</td>
<td>Defines "OI chunks" of data in ORDERED NUMERIC fields to enable more efficient range searching.</td>
</tr>

<tr>
<td>[[Field design#CONCATENATION-OF .28CAT.29 attribute|CONCATENATION-OF]]</td>
<td>(CAT)</td>
<td>Lists the fields that make up a concatenated field, and provides a concatenated value based upon the values of the constituent fields.</td>
</tr>

<tr>
<td nowrap>[[Field design#Counting occurrences of a field|COUNT-OCCURRENCES-OF]]</td>
<td>(CTO)</td>
<td>Automatically maintains a count of the number of occurrences of the specified field.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|CREATE-TIME]]</td>
<td>(CRTM)</td>
<td>Captures the time when the record was created, as of the start of the transaction.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|CREATE-TIMEUTC]]</td>
<td>(CRTMU)</td>
<td>Captures the Coordinated Universal Time when the record was created, as of the start of the transaction.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|CREATE-USER]]</td>
<td>(CRUS)</td>
<td>Captures the user ID of the user who created the record.</td>
</tr>

<tr>
<td>[[Field design#DATETIME-GE .28DTGE.29.2C DATETIME-GT .28DTGT.29.2C DATETIME-LE .28DTLE.29.2C and DATETIME-LT .28DTLT.29 attributes|DATETIME]]</td>
<td>(DT)</td>
<td>Specifies the format of the date and time data stored in Table B. The default is YYYYMMDDHHMMSSXXXXXX, i.e. to the nearest millionth of a second.</td>
</tr>

<tr><td>[[Field design#DATETIME-GE .28DTGE.29.2C DATETIME-GT .28DTGT.29.2C DATETIME-LE .28DTLE.29.2C and DATETIME-LT .28DTLT.29 attributes|DATETIME-GE]]</td>
<td>(DTGE)</td>
<td>With DATETIME-GT, DATETIME-LE, and DATETIME-LT, used to establish a range for date/time values. Specifies that the date/time value must be later than or the same as the date/time value that follows. </td>
</tr>

<tr>
<td>[[Field design#DATETIME-GE .28DTGE.29.2C DATETIME-GT .28DTGT.29.2C DATETIME-LE .28DTLE.29.2C and DATETIME-LT .28DTLT.29 attributes|DATETIME-GT]]</td>
<td>(DTGT)</td>
<td>Specifies that the date/time value must be later than the date/time value that follows.</td>
</tr>

<tr>
<td>[[Field design#DATETIME-GE .28DTGE.29.2C DATETIME-GT .28DTGT.29.2C DATETIME-LE .28DTLE.29.2C and DATETIME-LT .28DTLT.29 attributes|DATETIME-LE]]</td>
<td>(DTLE)</td>
<td>Specifies that the date/time value must be earlier than or the same as the date/time value that follows.</td>
</tr>

<tr>
<td>[[Field design#DATETIME-GE .28DTGE.29.2C DATETIME-GT .28DTGT.29.2C DATETIME-LE .28DTLE.29.2C and DATETIME-LT .28DTLT.29 attributes|DATETIME-LT]]</td>
<td>(DELT)</td>
<td>Specifies that the date/time value must be earlier than the date/time value that follows.</td>
</tr>

<tr>
<td>[[Field design#DEFAULT-VALUE .28DV.29 attribute|DEFAULT-VALUE]]</td>
<td>(DV)</td>
<td>Specifies the value to use for the field when the record is created and no value has been assigned to the field.

(The value of the STORE-DEFAULT setting determines whether the DEFAULT-VALUE is physically stored on the record or if it is just used as the default value when the field is missing.)</td>
</tr>

<tr>
<td>[[Field design#ESCAPE .28ESC.29 attribute|ESCAPE]]</td>
<td>(ESC)</td>
<td>Specifies an escape character to insert before separator and escape characters in a concatenated field, differentiating those characters from real data. The default value is X'01'.</td>
</tr>

<tr>
<td>[[Field design#AT-MOST-ONE.2C REPEATABLE and EXACTLY-ONE attributes|EXACTLY-ONE]]</td>
<td>(EXONE)</td>
<td>Specifies that a field always has exactly one occurrence in its record or field group context.
EXACTLY-ONE fields always appear first when output by a Print All Information (PAI) statement.</td>
</tr>

<tr><td>[[Field design#FIELDGROUP attribute|FIELDGROUP]]</td>
<td>(FG)</td>
<td>Specifies the name of the field group that the defined field is associated with (contained within).</td>
</tr>

<tr>
<td>[[Field design#FLOAT-GE .28FLTGE.29.2C FLOAT-GT .28FLTGT.29.2C FLOAT-LE .28FLTLE.29 and FLOAT-LT .28FLTLT.29 attributes|FLOAT-GE]]</td>
<td>(FLTGE)</td>
<td>With FLOAT-GT, FLOAT-LE, and FLOAT-LT, used to establish a range for float values when defining a field. Specifies that the float value must be greater than or equal to the value that follows.</td>
</tr>

<tr>
<td>[[Field design#FLOAT-GE .28FLTGE.29.2C FLOAT-GT .28FLTGT.29.2C FLOAT-LE .28FLTLE.29 and FLOAT-LT .28FLTLT.29 attributes|FLOAT-GT]]</td>
<td>(FLTGT)</td>
<td>Specifies that the float value must be greater than the value that follows.</td>
</tr>

<tr>
<td>[[Field design#FLOAT-GE .28FLTGE.29.2C FLOAT-GT .28FLTGT.29.2C FLOAT-LE .28FLTLE.29 and FLOAT-LT .28FLTLT.29 attributes|FLOAT-LE]]</td>
<td>(FLTLE)</td>
<td>Specifies that the float value must be less than or equal to the value that follows.</td>
</tr>

<tr>
<td>[[Field design#FLOAT-GE .28FLTGE.29.2C FLOAT-GT .28FLTGT.29.2C FLOAT-LE .28FLTLE.29 and FLOAT-LT .28FLTLT.29 attributes|FLOAT-LT]]</td>
<td>(FLTLT)</td>
<td>Specifies that the float value must be less than the value that follows.</td>
</tr>

<tr>
<td>[[Field design#INTEGER-GE .28INTGE.29.2C INTEGER-GT .28INTGT.29.2C INTEGER-LE .28INTLE.29 and INTEGER-LT .28INTLT.29 attributes|INTEGER-GE]]</td>
<td>(INTGE)</td>
<td>With INTEGER-GT, INTEGER-LE, and INTEGER-LT, used to establish a range for integer values when defining a field. Specifies that the integer value must be greater than or equal to the value that follows.</td>
</tr>

<tr>
<td>[[Field design#INTEGER-GE .28INTGE.29.2C INTEGER-GT .28INTGT.29.2C INTEGER-LE .28INTLE.29 and INTEGER-LT .28INTLT.29 attributes|INTEGER-GT]]</td>
<td>(INTGT)</td>
<td>Specifies that the integer value must be greater than the value that follows.</td>
</tr>

<tr>
<td>[[Field design#INTEGER-GE .28INTGE.29.2C INTEGER-GT .28INTGT.29.2C INTEGER-LE .28INTLE.29 and INTEGER-LT .28INTLT.29 attributes|INTEGER-LE]]</td>
<td>(INTLE)</td>
<td>Specifies that the integer value must be less than or equal to the value that follows.</td>
</tr>

<tr>
<td>[[Field design#INTEGER-GE .28INTGE.29.2C INTEGER-GT .28INTGT.29.2C INTEGER-LE .28INTLE.29 and INTEGER-LT .28INTLT.29 attributes|INTEGER-LT]]</td>
<td>(INTLT)</td>
<td>Specifies that the integer value must be less than the value that follows.</td>
</tr>

<tr>
<td>[[Field design#LENGTH-EQ .28LEQ.29 attribute|LENGTH-EQ]]</td>
<td>(LEQ)</td>
<td>Used to set a length constraint when defining a field. Specifies the required length of a field value.</td>
</tr>

<tr>
<td>[[Field design#LENGTH-GE .28LGE.29 attribute|LENGTH-GE]]</td>
<td>(LGE)</td>
<td>Specifies the minimum length of a field value.</td>
</tr>

<tr>
<td>[[Field design#LENGTH-LE .28LLE.29 attribute|LENGTH-LE]]</td>
<td>(LLE)</td>
<td>Specifies the maximum length of a field value.</td>
</tr>

<tr><td>[[Field design#Setting a pattern for a field value: the LIKE attribute|LIKE]]</td>
<td>(LK)</td>
<td>Sets a pattern that to which a field value must conform.</td>
</tr>

<tr>
<td>[[Field design#BLOB.2C CLOB.2C and MINLOBE attributes|MINLOBE]]</td>
<td>(MLBE)</td>
<td>Defines the minimum size of a BLOB or CLOB field value that will be stored in Table E. This avoids wasting Table E pages on small values that could be stored in Table B (or Table X). The default is 0.</td>
</tr>

<tr>
<td>NO-DOMAIN-CONSTRAINTS</td>
<td/>
<td>Specifies that the field has no [[Field design#Content constraints|content constraint]] attributes. Useful with <var>[[REDEFINE command|REDEFINE]]</var> to remove existing constraints on a field.</td>
</tr>

<tr>
<td>NO-DEFAULT-VALUE</td>
<td>(NDV)</td>
<td>Specifies that the field has no default value. Useful with <var>[[REDEFINE command|REDEFINE]]</var> to remove an existing default value on a field.</td>
</tr>

<tr>
<td>[[Field design#SEPARATOR .28SEP.29 attribute|SEPARATOR]]</td>
<td>(SEP)</td>
<td>Specifies a separator character used between field values in concatenated fields. The default is X'00'.</td>
</tr>

<tr>
<td>[[Field design#STORE-DEFAULT .28SD.29 and STORE-NULL .28SN.29 attributes|STORE-DEFAULT]]</td>
<td>(SD)</td>
<td>Specifies whether to physically store the default value for the field in each record, if no field value has been supplied and a default is required. The default option is LITERAL (LIT), which stores a literal string.</td>
</tr>

<tr>
<td>[[Field design#STORE-DEFAULT .28SD.29 and STORE-NULL .28SN.29 attributes|STORE-NULL]]</td>
<td>(SN)</td>
<td>Specifies whether to physically store the null value for the field in each record, if no field value has been supplied, and a default is required. The default option is LITERAL (LIT), which stores a literal string.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|UPDATE-TIME]]</td>
<td>(UPTM)</td>
<td>Captures the time when the record was updated, as of the start of the transaction.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|UPDATE-TIMEUTC]]</td>
<td>(UPTMU)</td>
<td>Captures the Coordinated Universal Time when the record was updated, as of the start of the transaction.</td>
</tr>

<tr>
<td>[[Field design#Automatic Fields|UPDATE-USER]]</td>
<td>(UPUS)</td>
<td>Captures the user ID of the user who updated the record.</td>
</tr>

<tr>
<td>[[Field design#UTF-8 and UTF-16 attributes|UTF-8]]</td>
<td>(UTF8)</td>
<td>Data is stored in UTF-8 format and is treated as unicode data inside SOUL programs. The default is EBCDIC.</td>
</tr>

<tr>
<td>[[Field design#UTF-8 and UTF-16 attributes|UTF-16]]</td>
<td>(UTF16)</td>
<td>Data is stored in UTF-16 format and is treated as unicode data inside SOUL programs. The default is EBCDIC.</td>
</tr>
</table>

==System management enhancements==

===Writing records to the SMF data set===
Having Model 204 write records to the SMF data set no longer requires the installation of an SVC.

Therefore, the <var>[[SMFSVC parameter|SMFSVC]]</var> parameter is no longer required and, if present, will be ignored and flagged with the following informational message:
M204.0204: PARAMETER SMFSVC OBSOLETE AND NOT RESET
However, the <var>[[SMFLORN parameter|SMFLORN]]</var> and <var>[[SMFSLRN parameter|SMFSLRN]]</var> parameters must still be present in CCAIN to specify the types of SMF record to be written.

===Providing a common CCAIN configuration with PRECCAIN===
A new feature in version 7.5 is the ability to [[PRECCAIN|provide a common configuration]] for all <var class="product">Model 204</var> jobs by linking <code>PRECCAIN</code> into your ONLINE, IFAM1, and/or IFAM4 load modules. <code>PRECCAIN</code>, an assembler module which you modify and link into the load modules, contains <var class="product">Model 204</var> commands and parameters set and executed, respectively, during <var class="product">Model 204</var> initialization.

==Performance enhancements==

===64-bit addressing and Above The Bar (ATB) storage===
Model 204 moves above the (2G) bar to increase scalability, performance, and growth potential. With this release of Model 204, 64-bit addressing becomes the de facto standard for all subsequent versions.

In addition to the ATB support for FTBL released with Model 204 version 7.4, version 7.5 adds ATB support for GTBL, NTBL, and QTBL, using the same <var>[[SERVNSA parameter|SERVNSA]]</var> and <var>[[SERVNSSZ parameter|SERVNSSZ]]</var> parameters used for FTBL.

When using non-swappable ATB server space, each user will get SERVNSSZ bytes of ATB space, even if the thread is logged out or running resident requests.

For greater efficiency, Model 204 version 7.5 also provides swappable ATB server areas that can supplement or replace the non-swappable areas. NTBL and QTBL can be stored in these swappable ATB server areas, which are controlled by the <var>[[SERVGA parameter|SERVGA]]</var> and <var>[[SERVGSZ parameter|SERVGSZ]]</var> parameters.

Note: Any assembler language functions that you have written for use within Model 204 version 7.5 must be 64-bit compliant. Contact Technical Support if you need help with conversion of your functions.

====GTBL, NTBL, QTBL in above the bar storage====
GTBL, NTBL and QTBL can now be placed into server storage above the bar.
In order to store a table in ATB storage:
<ul>
<li>Increase the <var>[[SERVNSSZ parameter|SERVNSSZ]]</var> parameter by the corresponding table size.
<li>Set the proper bit in <var>[[SERVNSA parameter|SERVNSA]]</var>:
<ul>
<li>for GTBL set the second byte to <code>X'80'</code>, so the value of <var>SERVNSA</var> is <code>X'00800000'</code></li>
<li>for NTBL set the third byte to <code>X'40'</code>, so the value of <var>SERVNSA</var> is <code>X'00004000'</code></li>
<li>for QTBL set the third byte to <code>X'20'</code>, so the value of <var>SERVNSA</var> is <code>X'00002000'</code></li>
</ul>
</ul>
'''Note:'''
The settings for each server table above the bar are independent of each other.
So if GTBL, NTBL, and QTBL are all placed above the bar, then <var>SERVNSA</var> should be set to <code>X'00806000'</code>.

====XmlDoc pages in above the bar buffer pool====
With this release, the CCATEMP pages used for <var>XmlDoc</var> objects use the above the bar buffer pool, which may allow the below the bar buffer pool to be reduced, perhaps providing more storage for server areas. It also may provide a reduction in CPU utilization, especially when the <var>[[TEMPPAGE parameter|TEMPPAGE]]</var> parameter is used to allocate CCATEMP in memory.

===Improved range searching by Ordered Index (OI) chunk===
The new <var>[[DEFINE FIELD command#Ordered index CHUNK attribute|CHUNK]]</var> attribute for the <var>DEFINE FIELD</var> command enables more efficient range searching on Ordered Index numeric (<var>ORDERED NUMERIC</var>) fields. <var>CHUNK</var> improves performance of the <var>FIND</var> statement <var>RANGE</var> and <var>BETWEEN</var> terms. The <var>CHUNK</var> field attribute defines a subrange ("OI chunk") of the data range. Searching by OI chunks on a range of data requires fewer scans of the ordered index entries to find the desired data. Once OI chunk fields are defined, they are automatically used by FIND processing, so no application code needs to be changed.

After defining an <var>ORDERED NUMERIC</var> field, you define one or more related OI chunk fields containing data from the original base field rounded down by a specified <var>CHUNK</var> size.

Example:
DEFINE FIELD YYYYMMDD WITH ORDERED NUMERIC
DEFINE FIELD YYYYMM WITH ORDERED NUMERIC INVISIBLE CHUNK 100 FOR YYYYMMDD
DEFINE FIELD YYYY WITH ORDERED NUMERIC INVISIBLE CHUNK 10000 FOR YYYYMMDD


<var>CHUNK</var> requires the <var>[[#FILEORG (new settings)|FILEORG]]</var> X'100' bit setting and the <var>INVISIBLE</var> and <var>ORDERED NUMERIC</var> field attributes.

==Debugging and testing enhancements==
The SoftSpy debugging, testing, and performance tuning product is now included as part of the Model 204 core product. For more information about SoftSpy version 7.5, see the [[Release notes for SoftSpy V7.5]].

==Connect★ enhancements==
The 7.5 version of Connect★ for JDBC, Connect★ for .NET, and Connect★ for ODBC is now available. Each interface contains the latest fixes and enhancements and is compatible with Model 204 version 7.5.

Additionally, Connect★ for JDBC and Connect★ for .NET contain the enhancements described below.

===Connect★ for JDBC===
Connect★ 7.5 for JDBC offers a "connection pooling" class to interface with other pooling infrastructures provided by pooling packages and web application servers. This new feature allows for a pool of connections that remain active and open during execution of an SQL and RCL (SOUL) statement.
Using connection pooling helps eliminate the overhead of creating initial connections from scratch or trying to
manage each connection using the JDBC API.

Each Connection Pool can create a pool of active connections maintainable throughout the connection cycle of the pooling service.

For a sample program, see the "Connect★ for JDBC" chapter of the <var class="book">Connect★ Installation and Programming Guide</var>.

Connect★ 7.5 for JDBC has been tested with the JNDI, Apache DBCPTM, BoneCP and C3PO pooling packages.

===Connect★ for .NET===
Connect★ 7.5 for .NET offers both 32-bit and 64-bit drivers that can be used with any Web or GUI-driven application.

==MQ/204 enhancements==

===Freeing MQ/204 subtasks and associated storage===
The new <var>MQDELDTP</var> PST (pseudo subtask) checks for MQ/204 subtasks that are in a delayed detach state. <var>MQDELDTP</var> detaches MQ/204 subtasks that have finished their work and releases their associated storage areas.
==Dictionary/204==
Dictionary/204 version 7.5 is compatible with Model 204 7.5 but does not include new features such as support for the version 7.5 [[#File-related enhancements|file-related enhancements]].

==Other features==
===AT-MOST-ONE and field groups===

The <var>AT-MOST-ONE</var> attribute is now applicable to a field group definition.

===Storing and updating LOBs===

All large object data (LOBs) in a <var>FILEORG</var> X'100' file are chained. There are four bytes per Table E page overhead for chained LOBs, used to maintain a queue of pages available for reuse after LOBs are deleted. The pages used by a chained LOB are not necessarily contiguous.


Handling LOBs in <var>FILEORG</var> X'100' files also has the following effects:
<ul>
<li>LOBs can be changed as needed. The <var>RESERVE</var> clause is ignored in a LOB field <var>ADD</var> statement processing, as well as the <var>STORE RECORD</var> statement processing of fieldname=value pairs. Consequently, the <var>CHANGE</var> statement does not fail because of insufficient reserved space. If the <var>CHANGE</var> statement requires that a LOB field be extended, it is.</li>

<li>The value of the <var>[[EHIGHPG parameter|EHIGHPG]]</var> parameter is always one less than the high water mark of the number of pages used to hold LOBs. (Unless none were ever added, in which case it is zero, not -1).</li>

<li>The value of the <var>[[EPGSUSED parameter|EPGSUSED]]</var> parameter is always the number of pages currently being used to hold LOBs.</li>

<li>The <var>COMPACTE</var> command does not process <var>FILEORG</var> X'100' files, just as it does not process a file created in V6R1 or earlier. Thus, issuing a <var>COMPACTE</var> command for a <var>FILEORG</var> X'100' file produces an error message.</li>

<li>The <var>TABLEE</var> command is effectively executing a <code>VIEW ESIZE EHIGHPG EPGSUSED</code> command for a <var>FILEORG</var> X'100' file. Consequently there are no <var>TABLEE</var> overhead pages in a <var>FILEORG</var> X'100' file.</li>
</ul>

===Constraint attributes===
You can set range constraints on fields using the constraint attributes. Each set of range attributes is comprised of four attributes (<var>GE</var>, <var>GT</var>, <var>LE</var>, <var>LT</var>) that you can use to establish a range for integer values, float values, or date-time stamp values. The types of range attributes are mutually exclusive. For example, you cannot define a field with the <var>FLOAT-GE</var> and <var>INTEGER-LE</var> attributes.

If a range constraint is redefined, it replaces the existing field constraint.

 Note: 
The range constraints do not have to match the data type of the stored field. That is, you could have a date-time constraint for a <var>STRING</var> field or an integer constraint for a <var>FLOAT</var> field, and so on.

You can set the following constraint attributes:
<ul>
<li>date-time value</li>
<li>pattern for a field value</li>
<li>length</li>
<li>integer value</li>
<li>floating point value</li>
</ul>

See [[Field design#Content constraints|Content constraints]] for details.

===Changes to journal record layouts===
Four bytes have been added to the journal record header for user statistic entries:
1 byte to hold the <var>IODEV</var> number and 3 bytes for future use.

All user since-last statistics (LAST=) lines will now show the <var>IODEV</var> value:
ST $$$ USERID='<var class="term">userid</var>' ACCOUNT='<var class="term">accountname</var>' IODEV='<var class="term">devicetype</var>' LAST='<var class="term">acty</var>'

For more information on journal records and user statistics, see the [[Using system statistics]] topic.

==Compatibility issues==
This section describes any compatibility issues between V7.5 and prior versions of Model 204.
An incompatibility arises if an operation that was previously performed without any indication of error, now operates (given the same inputs and conditions) in a different manner.

A normal bug fix resolving behavior that, although not indicating an error, was "clearly and obviously" incorrect, also introduces an incompatibility, but it might not be included below.

===Change to the Ordered Index layout===

Formerly all ORDERED NUMERIC fields came after all ORDERED CHARACTER fields in the Ordered Index. Now, the fields are interspersed in field code order.

===ZFIELD Image===

The [[ZFIELD image detail as of Model 204 V7.5|ZFIELD image]] has been updated for this release. The image is used with $LSTFLD and $FDEF function calls. One change is that FDEF is now longer (to accommodate FDEF1, LOOPVAR, and FDEF2).

===INTERCOMM is no longer supported===
The INTERCOMM interface supports the use of Teletype and 3270 terminals in line-at-a-time mode, using the Model 204 IODEV=29 thread type.

INTERCOMM is no longer supported as of Model 204 version 7.5.

See the <var class="book">Rocket Model 204 Terminal User's Guide</var> for a discussion of terminal interfaces.

===User PDL overflow===
The new <var>[[Release notes for Model 204 version 7.5 (DRAFT)#SEQPDL parameter|SEQPDL]]</var> parameter might require you to increase the size of the user Push Down List (using UTABLE LPDLST) by up to 3072 bytes, or more if you specify a value for SEQPDL that is larger than the 4096 default value.

===LPDLST parameter maximum value===
The maximum value for the <var>[[LPDLST parameter|LPDLST]]</var> parameter has been increased from 32760 to 65536.
The minimum value is now 10000.

===SSLIBSIZE parameter maximum value===
The maximum value for the <var>JANUS DEFINE</var> command <var>[[SSLIBSIZE (JANUS DEFINE parameter)|SSLIBSIZE]]</var> parameter has been decreased from 32767 to 16384.

===Mixed case messages by default===
As of version 7.5, all Model 204 messages are issued with mixed case text by default unless <var>[[UPCASMSG parameter|UPCASMSG]]</var> is set.

==New and changed commands==
Note: The [[Sirius Mods]] commands are merged with the <var class="product">Model 204</var> base as of <var class="product">Model 204</var> version 7.5, and they are available to version 7.5 customers. Sirius Mods commands with the same name as Model 204 commands are used with Sirius Mods features. Some Sirius commands are only available or useful at sites authorized for specific products. For details, see each individual command description on the [[List of Model 204 commands]] page. 
===Sirius Mods commands===
Sirius Mods commands now available in Model 204 7.5 are:
<ul>
<li>[[APPDATE command|APPDATE]]</li>
<li>[[BUMPSNAP command|BUMPSNAP]]</li>
<li>[[DUMP and DUMPX command|DUMP and DUMPX]]</li>
<li>[[DUMPG and DUMPGX command|DUMPG and DUMPGX]]</li>
<li>[[FILELOAD and FILELOADX command|FILELOAD and FILELOADX]]</li>
<li>[[FLOD and FLODX command|FLOD and FLODX]]</li>
<li>[[FNADDR command|FNADDR]]</li>
<li>[[FUDAEMON command|FUDAEMON]]</li>
<li>[[JANUS command|JANUS]]</li>
<li>[[JANUSDEBUG command|JANUSDEBUG]]</li>
<li>[[MONITOR operator command]]</li>
<li>[[RESTART operator command|RESTART operator]]</li>
<li>[[RESTAUTH command|RESTAUTH]]</li>
<li>[[RESTORE and RESTOREX command|RESTORE and RESTOREX]]</li>
<li>[[SAMPLE command|SAMPLE]]</li>
<li>[[SIRAPSY command|SIRAPSY]]</li>
<li>[[SIRFACT command|SIRFACT]]</li>
<li>[[SIRFIELD command|SIRFIELD]]</li>
<li>[[SIRIUS command|SIRIUS]]</li>
<li>[[SIRIUS DEBUG, SIRDEBUG, or SIRIUSDEBUG command|SIRIUS DEBUG, SIRDEBUG, or SIRIUSDEBUG]]</li>
<li>[[SIRMETH command|SIRMETH]]</li>
<li>[[STATUS command|STATUS]]</li>
<li>[[STOP command|STOP]]</li>
<li>[[UNICODE command|UNICODE]]</li>
</ul>


===DECREASE (new option: DYNAMIC)===
The DYNAMIC option on the <var>[[DECREASE command|DECREASE]]</var> command lets you decrease Table B dynamically, even if the file is open by others or has requests compiled against it.

===DEFINE DATASET (new parameter: GDGRECNT)===
The GDGRECNT parameter for the <var>[[DEFINE DATASET command|DEFINE DATASET]]</var> command causes Model 204 to check the catalog information for the latest relative GDG generation number whenever allocating a GDG data set.

===DEFINE FIELD (new or changed attributes)===
In Model 204 version 7.5, the <var>[[DEFINE FIELD command|DEFINE FIELD]]</var> command has new attributes information:
<ul>
<li>the new <var>[[#Improved range searching by Ordered Index .28OI.29 chunk|CHUNK]]</var> attribute, which improves the efficiency of range finds using ordered index processing</li>
<li>many other <var>[[FILEORG parameter|FILEORG=X'100']]</var> related new or changed [[Release notes for Model 204 version 7.5 (DRAFT)#New field attributes|field attributes]]</li>
</ul>

===DEFINE FIELDGROUP (new in V7.5)===
The <var>[[DEFINE FIELDGROUP command|DEFINE FIELDGROUP]]</var> command establishes the contents of a field group, including the fields and field groups associated with the field group being defined.

===DELETE FIELD (changed to handle CAT and CTO fields)===
The <var>[[DELETE command: Field|DELETE FIELD]]</var> command has been changed to take [[Field design#CONCATENATION-OF (CAT) attribute|CONCATENATION-OF (CAT)]] and [[Field design#Counting occurrences of a field|COUNT-OCCURRENCES-OF (CTO)]] fields into account. DELETE FIELD does not allow deletion of fields referred to by an existing CAT or CTO field.

===DELETE FIELDGROUP (new in V7.5)===
The <var>[[DELETE FIELDGROUP command|DELETE FIELDGROUP]]</var> command deletes a field group from a Model 204 file.

===DISPLAY FIELD (new option: COMMA)===
In Model 204 version 7.5, the <var>[[DISPLAY FIELD command|DISPLAY FIELD]]</var> command has added
the <var>COMMA</var> option, which uses commas to separate displayed field attributes.

===DISPLAY MODMAP (new in V7.5)===
<var>[[DISPLAY MODMAP command|DISPLAY MODMAP]]</var> displays the Model 204 link map in address order. System manager privileges are required.

===LOGFILE and LOGGRP (output format change)===
The <var>[[LOGFILE command|LOGFILE]]</var> and <var>[[LOGGRP command|LOGGRP]]</var> command output format has been changed so that:
<ul>
<li>File names in the <var>LOGFILE</var> command output are preceded by colons (as they are in <var>LOGCTL</var> commands for files). </li>

<li>Group names are preceded by commas (as they are for <var>LOGCTL</var> commands for groups). </li>

<li><code>********</code> is displayed as a password placeholder — the password is actually displayed for <var class="product">SirSafe</var>-controlled passwords. </li>
</ul>

===MSGCTL (new options: UP/UPPER, NOUP/NOUPPER)===
The <var>UP</var> (or <var>UPPER</var>) option on the <var>[[MSGCTL command|MSGCTL]]</var> command indicates that the specified message should be converted to uppercase before display. Similarly, the <var>NOUP</var> (or <var>NOUPPER</var>) option on the <var>MSGCTL</var> command undoes the effects of <var>UP</var> or <var>UPPER</var>.

===REGENERATE and REGENERATE ONEPASS (improved TO UPDATE option)===
The <var>TO UPDATE</var> option of the <var>[[REGENERATE command|REGENERATE]]</var> and <var>[[REGENERATE ONEPASS command|REGENERATE ONEPASS]]</var> commands can now handle multiple files.

If <code>TO UPDATE <var class="term">nn</var> OF <var class="term">id</var></code> is specified, it must appear only on the first <var>FILE</var> statement, and no other <var>TO</var> options are allowed on subsequent files.

All additional files are recovered as though they each specified the same <var>TO UPDATE</var> option. Once the "end of transaction" is reached, further processing stops and all inflight transactions are backed out.

===RENAME FIELDGROUP (new in V7.5)===
The <var>[[RENAME FIELDGROUP command|RENAME FIELDGROUP]]</var> command changes the name of a field group.

===UNICODE (new codepage: 1154)===
The <var>[[UNICODE command|UNICODE]]</var> command now accepts 1154 as a codepage name. This codepage has 92 Unicode characters in the range U+0400 through U+045F, representing the Basic Russian alphabet and all of the Cyrillic extensions excepting the four which have grave accents.


==Reliability enhancements==
===SEQPDL parameter===
The new <var>[[SEQPDL parameter|SEQPDL]]</var> parameter controls the amount of free space that must be present in the user's Push Down List (PDL) in order for the SOUL sequencer to proceed with the next quad code. The minimum and default value is 4096 bytes. The maximum value is 8192 bytes. <var>SEQPDL</var> is a user resettable parameter and can be set on the user's parameter line or reset with the UTABLE command.

Formerly 1024 bytes of PDL free space were hardcoded internally in the Model 204 core. With 1024 bytes there were edge cases where abends would break files, resulting in ERROR 2126: <code>USER'S PUSHDOWN LIST OVERFLOWED</code>. <var>SEQPDL</var> is provided to allow enough PDL space so that all of the lower level journaling routines can process error conditions without breaking files.

If your applications are using close to the amount of PDL space currently set by the LPDLST value, you might need to increase <var>[[LPDLST parameter|LPDLST]]</var> to reflect <var>SEQPDL</var>'s increase in free space.

==New and changed parameters==
In addition to the following specific parameter changes, <var class="product">Model 204</var> parameter descriptions, for example as displayed by the <var>VIEW</var> command, are now in mixed case (unless translated to uppercase due to <var>[[#UPCASMSG (new in V7.5)|UPCASMSG]]</var>.)

<blockquote class="note">Notes:
<ul>
<li>The [[Sirius Mods]] parameters are merged with the <var class="product">Model 204</var> base as of <var class="product">Model 204</var> version 7.5, and they are available to all version 7.5 customers. The combined set of parameters is displayed on the [[List of Model 204 parameters]] page. The former Sirius parameters in that listing are marked with an (S).
<li>A new feature in version 7.5 is the ability to [[PRECCAIN|provide a common configuration]] for all <var class="product">Model 204</var> jobs by linking <code>PRECCAIN</code> into your ONLINE, IFAM1, and/or IFAM4 load modules. <code>PRECCAIN</code>, an assembler module which you modify and link into the load modules, contains <var class="product">Model 204</var> commands and parameters set and executed, respectively, during <var class="product">Model 204</var> initialization.
</ul>
</blockquote>


===CUSTOM (additional settings)===
The CUSTOM parameter enables special modifications to Model 204. 17 new settings have been added to <var>[[CUSTOM parameter|CUSTOM]]</var> in V7.5.

===DEFCNTX and APDFCNTX (for $View function only, new in V7.5)===
The string
<code>DEFCNTX</code> or <code>APDFCNTX</code> can be used as an
argument to the <var>[[$VIEW|$View]]</var> function to
get the default file or group context. Using these strings is better than using <code>$View('CURFILE')</code> because:
<ul>
<li><code>CURFILE</code> returns a null string if the default context is a group.

<li><code>CURFILE</code> is affected by the <var>IN</var> clause prior to a <var>Begin</var> command and
can be affected by the <var>In</var> clause prior to many SOUL statements.
</ul>

If there is no default context, <code>$View('DEFCNTX')</code> returns a null
string.

Otherwise <code>$View('DEFCNTX')</code> returns the type of context (<code>FILE</code>, <code>TEMP GROUP</code>, or
<code>PERM GROUP</code>) followed by the file or group name, with trailing blanks
removed.

<code>$View('APDFCNTX')</code> returns the same information based on the default
context when the APSY was entered, unless that is the same as one of the files or groups in the subsystem's definition; in that case, the null string is returned.

Note: These <code>$View</code> arguments were implemented as part of
maintenance to version 7.5 (through zap number 54). They are not available as ordinary parameters on the <var>VIEW</var> command.
In version 7.6 of Model 204,
they will also be available with the <var>VIEW</var> command.


===DSPOPT (change to default setting)===
The default setting for <var>[[DSPOPT parameter|DSPOPT]]</var> has been changed from X'00' to X'01'. The X'01' setting allocates space for servers in memory in chunks of 4K pages, not as a permanent contiguous area. This allocation lets you move fewer 4K pages, keeping the virtual storage allocated for servers in memory less fragmented and possibly using fewer paging tables.

===ECPSIZE (change to max value)===
The maximum value setting for <var>[[ECPSIZE parameter|ECPSIZE]]</var> has been increased from 1310680 to 1966020 to accommodate more [[Release notes for Model 204 version 7.5 (DRAFT)#External Call Facility .28ECF.29|External Call Facility]] parameters.

===FILEORG (new settings)===
<ul>
<li>
The <var>[[FILEORG parameter|FILEORG]] X'100'</var> setting for enhanced data handling files is now available.

X'100' enables a number of enhancements to the file structure, including: 
<ul>
<li>[[Release notes for Model 204 version 7.5 (DRAFT)#Support for physical field groups|Support for physical field groups]] </li>

<li>The definition of as many as 32000 fields in a file </li>

<li>System maintained [[Field design#Automatic Fields|Automatic fields]] </li>

<li>[[Field design#Field constraints|Field constraints]] providing content validation </li>

<li>Improved space management of fields containing [[Field design#BLOB, CLOB, and MINLOBE attributes|Large Objects]] </li>

<li>[[#New field attributes|New DEFINE FIELD attributes]], such as <var>CHUNK</var>
</ul>

If X'100' is selected, the X'80' bit (optimized field extraction files) is automatically set.</li>

<li>The <var>FILEORG X'200'</var> setting for large file support is now available. </li>

X'200' allows files to hold up to 48 million records.
</li>
</ul>

===FISTAT (change to X'08' setting)===
The <var>[[FISTAT parameter|FISTAT]] X'08'</var> (file full) setting is now automatically cleared in a transaction back out file if table D is increased enough so that DSIZE is greater than or equal to DPGSRES+DPGSUSED.

===LRETBL (setting increase may be necessary)===
Because there might be a slight increase in record locking table usage in V7.5, an increase in the value of the <var>[[LRETBL parameter|LRETBL]]</var> parameter is advised. The amount of the increase is best estimated by multiplying by 16 the <code>HWM HEADERS</code> value (from a <var>[[MONITOR ENQ command|MONITOR ENQ]]</var> report), then dividing by the value of the <var>NUSERS</var> parameter. For example, if <code>HWM HEADERS = 100000</code> and <code>NUSERS=2000</code>, the recommended <var>LRETBL</var> increase is <code>16*100000/2000</code>, or 800.

===MISCOPT (obsolete)===
The <var>[[MISCOPT parameter|MISCOPT]]</var> parameter is now obsolete. In Model 204 version 7.5, MISCOPT is still viewable but is not resettable.

===MODTIM (new in V7.5)===
The <var>[[MODTIM parameter|MODTIM]]</var> system parameter displays the most recent assembly date and time of the Model 204 load module.

===OUTPUT (change to allow OUTPUT=DUMMY)===
IODEV=3 threads definitions now allow OUTPUT=DUMMY.
When defining IODEV=3 threads, if output is not required, the OUTPUT parameter can be coded as OUTPUT=DUMMY.
For example:
IODEV=3,INPUT=IOD3IN1,OUTPUT=DUMMY
IODEV=3,INPUT=IOD3IN2,OUTPUT=DUMMY
IODEV=3,INPUT=IOD3IN3,OUTPUT=DUMMY
and so on.

This means that no DD statement is required for the output data set, and in cases where many
IODEV=3 threads are defined to simulate a large number of users, this enhancement will reduce the number of DD statements required by one half.

===RECLOCKO (X'04' bit now ignored)===
The <var>[[RECLOCKO parameter|RECLOCKO]]</var> X'04' bit is now ignored, and the extra information of the conflicting user number and lock time are now always available.

===RESPAGE (new in V7.5)===
The <var>[[RESPAGE parameter|RESPAGE]]</var> parameter activates the APSY Precompiled Procedures in storage feature using above the bar pages by specifying a number of 4K operating system pages.

Specifying RESPAGE stores precompiled procedures as resident requests above the bar in the RESPAGE area. Using RESPAGE allows you to substantially increase the resident request area and decrease server swapping of QTBL and NTBL pages.

Also, when RESPAGE is used, RESSIZE is reset and the storage below the bar specified by RESSIZE is no longer used.

Storing resident requests above the bar is independent of tables above the bar. You can use a combination of resident request and swappable servers ATB to reduce below the bar server sizes and thus increase the number of servers.

===RETRVKEY (change to allow forward retrieve PF key)===
New in this release, if you specify a non-zero setting of <var>[[RETRVKEY parameter|RETRVKEY]]</var>:
<ul>
<li>If you have set the <code>X'01'</code> or <code>X'10'</code> bits of the <var>[[RETRVOPT parameter|RETRVOPT]]</var> parameter, you can use a
forward retrieve PF key, in addition to the backward retrieve PF key specified by <var>RETRVKEY</var>.
'''Note:'''
If either of these bits is set, the <code>X'02'</code> bit is strongly recommended as well.
<li>The size of the allocated storage area, and hence the number and length of input lines available for retrieval, is specified
by the value of the <var>[[RETRVBUF parameter|RETRVBUF]]</var> parameter.</ul>

===SEQPDL (new in V7.5)===
The <var>[[Release notes for Model 204 version 7.5 (DRAFT)#SEQPDL parameter|SEQPDL]]</var> parameter controls the amount of free space that must be present in the user's Push Down List in order for the SOUL sequencer to proceed with the next quad code. SEQPDL allows enough PDL space for the lower level journaling routines to handle error conditions properly without breaking files and causing ERROR 2126 USER'S PUSHDOWN LIST OVERFLOWED.

===SESMAXTO (new in V7.5)===
The <var>[[SESMAXTO parameter|SESMAXTO]]</var> parameter can be used limit the maximum [[Sessions|session]] timeout value or to cause all current closed sessions to be immediately discarded.

===SMFSVC (obsolete)===
The <var>[[SMFSVC parameter|SMFSVC]]</var> parameter is [[Release notes for Model 204 version 7.5 (DRAFT)#Writing records to the SMF data set|obsolete]] as of Model 204 version 7.5.
===SNAPCTL (change to default setting)===
The default setting for <var>[[SNAPCTL parameter|SNAPCTL]]</var> has been changed from X'41' (X'44' under CMS) to X'28'. The X'28' setting results in smart snaps – relatively small snaps with all the information that is likely to be required to diagnose the cause of the snap. This setting allows snaps to be taken quickly, and for those snaps being easily sent to Rocket support with little or no adverse effect on the possibility of diagnosing the cause of the snap.

===UPCASMSG (new in V7.5)===
The <var>[[UPCASMSG parameter|UPCASMSG]]</var> parameter can be used to translate messages issued by <var class="product">Model 204</var> to uppercase; otherwise (depending on the message being issued) they are displayed in mixed (upper and lower) case.




==Notes for system manager and installer==
===Upgrading instructions for version 7.5===
Model 204 version 7.5 is an upgrade to Model 204 version 7.4.

In order to upgrade to version 7.5, you must have version 7.4 and Autofix release EW3044 installed on your system.

Autofix release EW3044 includes:
<ul>
<li>Early Warnings for Model 204 through 740EW172</li>
<li>Early Warnings for Dictionary/204 through 740DI016</li>
</ul>

For detailed instructions, see the [[Model 204 installation]] pages.

===PRECCAIN: sharing configuration for all Model 204 jobs===
A new feature in version 7.5 is the ability to [[PRECCAIN|provide a common configuration]] for all <var class="product">Model 204</var> jobs by linking <code>PRECCAIN</code> into your ONLINE, IFAM1, and/or IFAM4 load modules. <code>PRECCAIN</code>, an assembler module which you modify and link into the load modules, contains <var class="product">Model 204</var> commands and parameters set and executed, respectively, during <var class="product">Model 204</var> initialization.

===Extended attribute volume (EAV) support for Fast/Reload===
In version 7.5, the Fast/Reload product now functions correctly when a <var class="product">Model 204</var> file is stored, or partially stored, on an Extended Attribute Volume (EAV).

==Documentation conversion to wiki format==
Rocket Model 204 documentation is being converted from individual manuals in PDF format to a set of cross-linked HTML articles in this integrated wiki, M204wiki.

As of Model 204 release 7.5, several manuals are now in wiki format and the rest remain in PDF format, available in the M204 folder of the [http://docs.rocketsoftware.com/nxt/gateway.dll?f=templates$fn=default.htm Rocket Software Documentation Library].

For details, see [[Model 204 documentation]].

==New and updated messages==

Many messages have been updated and added in this release. See [[New and updated messages in Model 204 version 7.5]] for details.

[[Category: Release notes]]

Mixed-case SOUL

2014-06-19T16:07:16Z

Teagan: Moved mention of 'introducing mixed case in Model 204 7.5' from paragraph three in background to opening paragraph below title. Tweaked wording from what would have been an incomplete sentence.

You can compose a <var class="product">User Language</var> (now <var class="product">SOUL</var>) request in case-insensitive mode.
When in this mode, all elements of a <var class="product">SOUL</var> program excepting ''literal strings'' are processed after converting lowercase letters to uppercase. <var class="product">SOUL</var> includes enhanced support for mixed case as of <var class="product">Model 204</var> V7.5.

===Background===
One of the principles generally accepted in object-oriented programming is that variable
names and method names should be meaningful, that is, be full words or phrases
rather than abbreviations or shorthands.
For example, it is generally considered better to call a variable <code>%FIRSTNAME</code> rather than <code>%FN</code>.
The reason for this is that most programmers spend much more time reading code
than writing it, and meaningful variable names make reading much easier than
terse abbreviations.
And even when writing code, programmers will typically spend more time
thinking about what they are writing than actually typing it and, here again,
the thinking process is facilitated with meaningful names.

Meaningful names often involve creation of compound words as variable names such as <code>%OLDESTCHILDBIRTHDATE</code>.
As this example illustrates, however, these names can become difficult to read as they become more descriptive.
One way to deal with this problem is with the use of separator characters such as underscores or periods, as in <code>%OLDEST_CHILD_BIRTH_DATE</code> or <code>%OLDEST.CHILD.BIRTH.DATE</code>.
The problem with this approach, however, is that it can make code look like "special-character soup" with a mish-mash of inter- and
intra-variable separator characters which makes visual parsing difficult.
The approach most commonly used in object-oriented programming is to use case to separate words in a compound word variable name, for example, <code>%OldestChildBirthDate</code>.
There are basically two standards for compound word capitalization:
the [http://en.wikipedia.org/wiki/Camel_case camel case] format, where the first word is not capitalized as in <code>%oldestChildBirthDate</code>, and the [http://en.wikipedia.org/wiki/Pascal_%28programming_language%29 Pascal] format (after the programming language) where the first word is capitalized, as in <code>%OldestChildBirthDate</code>.

Regardless of the chosen scheme for capitalizing, mixed case is useful for providing code readability.
This is true not just for compound variable names, but for <var class="product">SOUL</var>
statements in general — imagine if books were written entirely in uppercase.
Mixed case facilitates the use of a coding style common to most object-oriented languages.

Historically, <var class="Product">[[Model 204]]</var> <var class="product">User Language</var> was actually a case-sensitive
language with uppercase keywords.
This means that keywords such as IF, THEN, FOR, ADD, etc. had to be
written in uppercase.
There are basically three approaches to providing support for mixed case:
<ol>
<li>Case-sensitive with lowercase or mixed-case keywords. This is the approach used in languages such as [http://en.wikipedia.org/wiki/C_%28programming_language%29 C] and [http://en.wikipedia.org/wiki/Java_%28programming_language%29 Java]. Unfortunately, it was too late for this approach in <var class="product">User Language</var> as the language already has case-sensitivity with uppercase keywords. While it might have been possible to use this approach with lowercase variants of all keywords, such an approach would have been complex, and the case-sensitivity for variable names would make migration to mixed-case code extremely difficult as explained in the next item.

<li>Case-insensitive for keywords but case-sensitive for variable names. A few languages use this approach, but it is quite complex to implement because it makes case-insensitivity of tokens depend upon context. Furthermore, it makes code migration extremely difficult — all references to a variable must be changed to the correct mixed-case variant at once before any of them can be changed. This can be very difficult to do, especially for ''Common'' variables that are used in many different pieces of code, so it is likely that any case-sensitive approach would result in some variables remaining indefinitely in uppercase.

<li>Case-insensitivity for keywords and variable names. Because this seemed to provide the best migration path to using mixed case in existing applications, this approach was taken in <var class="product">SOUL</var>. It is probably for these very reasons that many other languages with uppercase keyword roots such as [http://en.wikipedia.org/wiki/Visual_Basic Visual Basic], [http://en.wikipedia.org/wiki/COBOL Cobol], [http://en.wikipedia.org/wiki/Fortran Fortran], and many others have taken the same approach toward providing support for mixed case.
</ol>
It is worth noting that, at least in theory, case-insensitive <var class="product">User Language</var> is a major backward compatibility problem.
Before the mixed-case support, ''%customer'' was a different variable from <code>%Customer</code> or <code>%CUSTOMER</code>.
Fortunately, because of <var class="product">User Language</var>'s requirement for uppercase-only keywords, few people took advantage of this case-sensitivity
because it just looked "funny" to have mixed-case variables afloat in a sea of uppercase keywords:
IF %status = 'new' THEN
READ SCREEN newCustomer
IF %newCustomer:PFKEY EQ 3 THEN
STOP
END IF
END IF

So, ''probably'' most existing <var class="product">User Language</var> applications will work
fine in case-insensitive mode with no modifications.
However, since there is no way for <var class="product">SOUL</var> to know that this is the case,
programmers must indicate that programs are to be case-insensitive.

Perhaps somewhat counter-intuitively, case-insensitivity is achieved
by internally translating all unquoted tokens to uppercase.
That is, <code>%customer</code>, <code>%Customer</code>, and <code>%CUstOMer</code> all refer to the same
variable because they all get internally translated to <code>%CUSTOMER</code> before being processed.
Similarly, <code>if</code>, <code>If</code>, and <code>IF</code> all get translated to <code>IF</code> before being compiled.
This translation is useful in allowing reference to existing uppercase fieldnames
in mixed case.
For example, field <code>RECTYPE</code> could be referred to as <code>recType</code> when
case-insensitive <var class="product">SOUL</var> is enabled.
Translation of tokens to uppercase also means that compiler error
messages will sometimes indicate names or keywords in uppercase, even though
they were entered in mixed case.

The following sections summarize the entities affected by uppercase translation
and describe how to invoke it.

===What is affected===
If <var class="product">SOUL</var> case-insensitivity is enabled, these entities become case-insensitive:
<ul>
<li>'''SOUL keywords'''. For example: <var>For</var>, <var>If</var>, <var>Then</var>, <var>eq</var>.

<li>'''Names of members of SOUL classes'''. For example: [[XmlDoc API]], [[File classes|File class]], and [[HTTP Helper]] methods and variables.

<li>'''Variable elements'''. For example: %variables, Screen/Image names and items, Class/Structure members. Note, however, that in this mode you cannot define two variable elements whose names differ only because some letters have different case.

<li>'''Labels and subroutine names'''. Note: In this mode, you cannot define two labels whose names differ only because some letters are different case. 

<li>'''Field names'''. Note: In this mode, you cannot access field names containing lowercase letters. 

<li>'''$functions'''. Note: In this mode, you cannot access $functions containing lowercase letters. 

<li>'''Procedure names''' (on the Include statement). Note: In this mode, you cannot include procedures whose names contain lowercase letters. 

<li>'''SOUL object documentation'''. Keywords and variable name references use mixed case. Keywords will generally be indicated by an uppercase first letter.
</ul>

===What is not affected===
If <var class="product">SOUL</var> case-insensitivity is enabled, these entities '''do not''' become case-insensitive:
<ul>
<li>'''Model 204 commands''' (except for Begin, which is discussed below). Command processing usually works well, however, if you use *UPPER for command input, and let the modifications to the Model 204 editor (including the <var>[[SIREDIT parameter|SIREDIT]]</var> parameter and the editor ''CASE'' command) be in effect for working on <var class="product">SOUL</var>.

<li>'''Quoted strings''' (in a <var class="product">SOUL</var> request). For example: <code>'Caps help with veryLongNames'</code>.

<li>'''Literal contents of a Text/Html block'''. In a Text/Html block, case is preserved for all elements except those enclosed in the evaluation brackets (curly braces). In the following example, <code>empName</code> and <code>empAddress</code> are references to fields named EMPNAME and ADDRESS, respectively:
Html
Name: {empName}
Address: {empAddress}
End Html 

<li>'''Non-compilation elements'''. Case-insensitive processing applies only to program elements encountered during compilation. For example, when setting a value for a fieldname variable or for Screen or Image indirection, the value must exactly match the name. If you have a field named EMPNAME and you reference it with a fieldname variable, the value used must be all uppercase:
Begin
%x String Len 20
%x = 'EMPNAME'
FR
Print %%x
End For
End 
</ul>

===How to enable and disable===
You can enable case-insensitive <var class="product">SOUL</var> in one of these ways:
<ul>
<li>Start a program with a mixed-case or lowercase <var>Begin</var> statement.

<li>Use the <code>Sirius Case ToUpper</code> compiler directive.

<li>Use the <var>[[COMPOPT parameter|COMPOPT]]</var> system parameter to globally enable case-insensitive <var class="product">SOUL</var>.
Because the following programs begin with mixed-case <var>Begin</var> statements,
they are compiled with case-insensitivity:
b
print 'Mixed case UL is easy'
end 
Or:
Begin
Print 'Style is everything'
End 

Sometimes, however, one might be working on <var class="product">SOUL</var> that is Included
in many outer programs, some of which might not have been converted to
case-insensitivity yet.

In such a case, it is possible to enable internal translation to uppercase
(and so case-insensitivity) with the <code>Sirius Case</code> compiler directive:

Sirius Case {ToUpper | Leave} 

Specifying <code>ToUpper</code> requests internal uppercase translation; <code>Leave</code> means no such translation.

If procedure ''P'' contains a complex subroutine that might
be included in outer procedures, some of which might not have been converted
to use case-sensitivity, you can insert a <var>Sirius Case</var> directive
at the top of procedure:

sirius case toUpper
subroutine mixedUp(%confusion is float)
...
end subroutine 

The <var>Sirius Case</var> directive affects case translation in Included
procedures unless explicitly overridden in those procedures.
The <var>Sirius Case</var> setting does '''not''' affect the procedure
that Included the procedure with the setting
(so, case-sensitivity in a procedure can never be changed by an Included procedure).

Because the <var>Sirius Case</var> directive is a compiler directive, it is not
affected by any programming block structures (such as <var>For</var> loops).
It simply affects all lines of code physically after the directive.

<code>Sirius Case Leave</code> can be used to turn off case-insensitivity in
cases where case-sensitivity is required or desired.
Note, though, that in such cases, all <var class="product">SOUL</var> keywords must be in uppercase.

====The COMPOPT system parameter====
The system parameter <var>[[COMPOPT parameter|COMPOPT]]</var> facilitates migration to mixed-case <var class="product">SOUL</var>.
<var>COMPOPT</var> is a Model 204 bitmask parameter that must be set in the CCAIN (User 0 input) stream.
The bits in <var>COMPOPT</var> have the following meanings:
<dl>
<dt>X'01'
<dd>If on, all procedures start out in <code>Sirius Case ToUpper</code> mode,
whether or not they begin with a mixed-case <var>Begin</var> statement.
<code>Sirius Case ToUpper</code> mode translates all unquoted tokens to uppercase, so
<var class="product">SOUL</var> statements, keywords, variable names, etc. may be written in mixed case.
By setting the <var>COMPOPT</var> X'01' bit, a site is essentially enabling mixed-case <var class="product">SOUL</var> almost everywhere.

<dt>X'02'
<dd>If on, <code>Sirius Case Leave</code> compiler directives are to be ignored:
if <code>Sirius Case ToUpper</code> is in effect, it remains in effect even
if a <code>Sirius Case Leave</code> directive is encountered.
Setting the <var>COMPOPT</var> X'02' bit along with the X'01' bit enables mixed-case <var class="product">SOUL</var>
everywhere, thus ensuring consistent language processing throughout an Online.

<dt>X'04'
<dd>If on, image or image-item names, either literal or in variables,
are to be automatically converted to uppercase before being used in methods or
$functions.
Since mixed-case <var class="product">SOUL</var> is accomplished by translating unquoted tokens to
uppercase, this case conversion for image or image-item names is the runtime
equivalent of the compiler mixed-case support.

Setting the <var>COMPOPT</var> X'04' bit enables image and image-item names that
appear as literals in <var class="product">SOUL</var> programs to be entered in mixed case.
The only time this might be a problem is if there are true mixed-case image
or image-item names in an application. 

A true mixed-case image or image-item name is one written in mixed case,
either inside quotation marks (image and image-item names can ''indeed''
be put in quotes) or without <code>Sirius Case ToUpper</code> in effect.
In general, neither of these is too likely, so true mixed-case image or
image-item names are not likely in most applications. 
</dl>