Storing security information (CCASTAT)

Overview

CCASTAT is a sequential data set containing a password table of user and file security information in an encrypted format. All Model 204 security features depend upon the existence of CCASTAT.

This page describes how to create and use CCASTAT.

For additional information about security and modification of CCASTAT, see Establishing and maintaining security.

Creating CCASTAT

Before you can turn on any security options, you must create a prototype password table using the utility program ZBLDTAB.

Note: When installing external security interfaces with Model 204, you must still define a CCASTAT file that contains at least one entry.

z/OS procedures

Use the following z/OS JCL to create CCASTAT:

//EXEC PGM=ZBLDTAB,REGION=50K //STEPLIB DD DSN=M204.LOADLIB,DISP=SHR //CCASTAT DD DSN=M204.CCASTAT,UNIT=3330, // SPACE=(TRK,(2,1)),DISP=(NEW,CATLG), // DCB=BLKSIZE=13030

• You can specify any direct access unit and any BLKSIZE. If no BLKSIZE is specified, ZBLDTAB assigns a default BLKSIZE of 6302 bytes.
• Secondary extents, if defined in the SPACE parameter, will be taken (as needed), as new entries are added and the data set grows.
• Each password table entry that does not have terminal security requires 26 bytes. (For more information, see Terminal security.)

z/VM procedures

When running under z/VM/CMS, the ZBLDTAB utility program initializes a Model 204 password table. The format of the ZBLDTAB command is:

ZBLDTAB [datasetname] [filename filetype] [filemode]

Where:

• datasetname specifies the name of the password table data set on a variable-format disk, with the qualifiers separated by blanks. If the specified disk is variable-format and if no datasetname operand is specified, it is presumed that the name of the password table data set is M204.CCASTAT.
• filename and filetype signify the name and type of the password table file on a CMS-format disk.

z/VSE procedures

The z/VSE JCL statements required to execute ZBLDTAB are as follows:

// JOB ZBLDTAB BUILD MODEL 204 SECURITY FILE // DLBL M204LIB,'M204.PROD.LIBRARY' // EXTENT SYSnnn,... // LIBDEF PHASE,SEARCH=M204LIB.V411 // DLBL CCASTAT,'security file-id',0,SD // EXTENT SYS001,balance of extent information // ASSGN SYS001,X'cuu' // EXEC ZBLDTAB /* /&

• The amount of disk storage must be sufficient to contain two Model 204 pages, 6184 bytes each.
• The minimum allocation for FBA devices is 26 blocks.
• You must provide the full EXTENT information for the file for the execution of ONLINE or BATCH204, if you are updating the password table with the LOGCTL command.
• You must turn on the UPSI switch 3 (SYSOPT=16) to activate Model 204 security facilities:

UPSI 00010000

Using CCASTAT

Data set definitions (z/OS, z/VSE, z/VM)

Runs that use security options require the following DD statement in their z/OS JCL:

//CCASTAT DD DSN=M204.CCASTAT,DISP=SHR

Use the following statements for z/VSE (see z/VSE considerations below):

// DLBL CCASTAT,'M204.CCASTAT',0,SD // EXTENT SYSnnn, (balance of extent info) // ASSIGN SYSnnn, X'cuu'

z/VM/CMS requires a FILEDEF. For example:

FILEDEF CCASTAT G DSN M204 CCASTAT

Encryption prevents security breaches of the password table itself. Decryption occurs when a disk copy of the table is read into main memory. If Model 204 cannot decrypt the table, it produces a message stating that the password table has been corrupted.

z/VSE security considerations

Under z/VSE, the password table is a standard sequential disk file. When a LOGCTL command is entered that requires the CCASTAT data set to be updated, the file is closed for input, opened for output, and written to disk.

If the file has not expired, the operating system issues a message indicating that the existing file is going to be overlaid as a result of the operation:

EQUAL FILE IN VTOC CCASTAT

To complete the update of the password table, the operator must respond to the message. If a response other than DELETE is given, the operating system attempts to cancel the ONLINE job stream. A message indicating that a STXIT has been trapped is issued.

To circumvent the STXIT message and the attendant operator response, you can create the CCASTAT data set with a retention period of zero, as in the DLBL example above. However, the resulting file might be vulnerable to inadvertent erasure by other applications without notice.

If CCASTAT is given a zero retention period, use the ALLOCATE utility to allocate two dummy data sets with a retention period of 99/365. Allocate the first data set to immediately precede CCASTAT and allocate the second to immediately follow it.

Login security

Login security limits access to Model 204 by requiring individual users to enter a user ID and a valid password when logging in.

• If users are required to log in, every user must enter a valid ID after the LOGIN or LOGON command, followed by a valid password, if one is specified for the user ID. The ID and password are used by Model 204 to determine authorization to use Model 204 and the type of operations available to the user.
• If users have the option of logging in to the system and a password table is available, user privileges are granted in accordance with the entries in the password table.

  The password requirements and restrictions are the same whether a user resets their password at login or it is reset via the LOGCTL command.

• If a user does not issue a LOGIN or LOGON command, Model 204 assumes that the user has superuser privileges.

Login implementation

To implement login security, include the following in the JCL:

• Setting of 16 on the SYSOPT parameter.
• CCASTAT statement in the JCL for the run that points to a previously created password table data set. The discussion of the password table data set starts in Password table data set, below.
• Specification of the number of consecutive times a login can fail (LOGTRY parameter) before Model 204 takes a specified action (LOGFAIL parameter).

  Set LOGTRY and LOGFAIL on User 0's parameter line. You can reset LOGTRY during a Model 204 run.

Login delays

In addition to the LOGTRY and LOGFAIL parameter options, an additional, automatic security feature is invoked for threads on which users make repeated attempts to login and fail due to invalid ID-password combinations.

When login is required, if an invalid user ID and password combination is supplied, an internal count used in the LOGTRY comparison is incremented. On the fourth-failed login attempt, the login process for this thread begins to slow down. The error count is used as the basis for a calculation that increases according to the function N*(N-1), where N is the number of failed login attempts.

A valid user ID and password combination immediately clears the error count and eliminates the delay. During login service delays, Model 204 also drops the login service priority level from 255 to 0, and marks the offending thread as pending login due to errors.

LOGFAIL actions still occur. The user can be bumped by a user with operator or system manager privileges. Even if a bump is performed, the failing error count is not reset until a valid login on that thread occurs. Other Model 204 users and Model 204 itself are not affected by the time delay on a failed login, other than the effect that the pending login has by tying up a thread.

To monitor the system for unsuccessful logins use the MONITOR, LOGWHO, and STATUS commands. A wait type (WT) of 23 from the MONITOR command indicates that a login for the thread is pending; flags (FLGS) indicate that the user is swappable and bumpable.

Password table data set

The password table contains one entry for each user allowed to log in to Model 204. Each entry contains the following information:

• User ID
• Password associated with the ID
• Privilege byte (summed), as shown in the following table, indicating the privileges and access rights available to the user after a successful login
• Priority setting indicating the priority at which the user is allocated system resources

  Privilege byte settings

  Setting	Meaning
  X'80'	Superuser privileges. The user can create files (CREATE).
  X'40'	System administrator privileges. The user can issue privileged commands (MONITOR, PRIORITY, WARN, and others).
  X'20'	The user can change the file password when it is used to open a file.
  X'10'	The user can change the login password when logging in to the system.
  X'08'	System manager privileges. The user can issue privileged commands (LOGCTL, DUMPG, IFAMDRAIN and others).
  X'04'	The user can override record security.

The password table is stored on disk in an encrypted form to prevent unauthorized users from examining its contents. Password table decryption occurs whenever a disk copy of the table is read into main memory. If Model 204 cannot decrypt the table, a message is issued stating that the password table is corrupted.

Because the information in the password table is in coded form, it is relatively protected from unauthorized access. If more protection is desired, consider IBM utility security on the CCASTAT data set. Model 204 must be given update privileges for any additional security.

Password table maintenance

You can add, delete, or change entries in the password table using the LOGCTL command. The following sections explain how to:

• Perform these maintenance functions
• Process password table updates
• Back up the password table

One of the first maintenance actions is to add a new user ID that includes system manager privileges. Then modify the SUPERKLUGE entry by changing the password and privileges, or by deleting it entirely.

Issue the LOGLST command to obtain a listing of all login user IDs with associated privileges, but not the passwords.

Refer to z/VSE procedures for instructions on creating CCASTAT and z/VSE-specific considerations.

Backing up the password table

Make backup copies of CCASTAT regularly by using an IBM utility or maintaining a card deck that consists of all the LOGCTL A commands executed to date. If you use a card deck, you can reconstruct CCASTAT by running the ZBLDTAB utility and BATCH204.

Adding entries

To add new login passwords, user privileges, and priorities for specified user IDs:

1. Use the LOGADD parameter on User 0's parameter line to specify the number of slots for new entries to be added to the password table during a run.
2. Issue the LOGCTL A command.

   If the specified user ID is already in the table, or if no slots are available, you receive a message.

By specifying non-numeric user IDs, you can avoid the ambiguity that can result in commands that accept user IDs or user numbers as arguments.

Deleting entries

To delete login password table entries, use the LOGCTL D command.

If the user ID does not exist in the password table, Model 204 returns a message stating that the specified entry was not found. If the user ID is found, the password table entry is deleted and the space can be reused for a password table addition during the run.

Changing entries

To change login password table entries, use the LOGCTL C command:

• The user ID must already exist in the password table. If it does not, Model 204 issues a message indicating that the entry was not found.
• If an entry is omitted, the corresponding entry already in the password table is preserved.
• Delimiters are required as place holders if an entry is not changed. For example:

  ,X'80',NONE Change privileges and priority ,,HIGH Change priority

A sample dialogue using LOGCTL

The following dialogue illustrates the use of LOGCTL in adding, changing, and deleting user IDs:

LOGCTL A WASHBURN *** M204.0374: ENTER PASSWORD,PRIVILEGES,PRIORITY SESAME,X'80',HIGH *** M204.0379: ENTER TERMINAL LIST,ALL,NONE,ADD,DEL,OR RETURN 3,4,7,21 LOGCTL C ABARTH *** M204.0374: ENTER PASSWORD,PRIVILEGES,PRIORITY *** M204.0379: ENTER TERMINAL,ALL,NONE,ADD,DEL,OR RETURN LOGCTL D SMITH

Before making any change permanent, Model 204 displays the new password table entry for an add or change and the old entry for a delete. If the display is interrupted with an ATTENTION, the change is not made.

Processing login password table updates

The password table can be updated by concurrently running copies of Model 204 without preventing a subsequent update to the same table. In order for concurrently running copies of Model 204 to update the password table, the in-core version of the table must have sufficient core storage allocated to it by the run. The amount of core storage allocated is determined by:

• Size of CCASTAT when Model 204 was initialized
• Value of the LOGADD parameter

Updates that exceed allocated storage

A password table update can enlarge the disk version, which might make the disk version too large to fit into the core storage allocated for the table by a concurrently running job that attempts a subsequent update to the table. For example:

1. Job A and Job B are concurrently running copies of Model 204 using the same password table data set. Job A has LOGADD set to 7; Job B has it set to 5.
2. Job A updates the password table, adding six passwords.
3. Job B cannot update because not enough storage to hold the new disk version of the password table was allocated.

In this situation, if the run with insufficient storage attempts to update the password table, it receives these messages:

*** M204.0312: DISK VERSION OF PASSWORD TABLE TOO LARGE TO READ INTO ALLOCATED STORAGE *** M204.0343: CHANGE APPLIES ONLY TO THIS RUN; UPDATES TO CCASTAT NOT ALLOWED

To avoid having too little storage allocated for the password table, all jobs that update the same password table should specify the same value for LOGADD. However, if the password table is updated by a job before other jobs that run concurrently are initialized, the problem of insufficient storage can still arise.

For example:

1. Job A initializes with a LOGADD value of 5.
2. Job A updates the password table, adding three passwords.
3. Job B, using the same password table, initializes with a LOGADD value of 5.
4. Job B updates the password table, adding three passwords.
5. Job A does not have enough storage even though both jobs specified the same value for LOGADD. Job B initialized after Job A updated the password table and, as a result, Job B was allocated a greater amount of core storage during initialization.

Multiple copies of Model 204

A copy of Model 204 running concurrently with other copies does not automatically have access to the updates made by the other copies. For example:

1. Job A and Job B are concurrently running copies of Model 204 that use the same password table data set.
2. Job B updates the password table.
3. Job A does not have access to Job B's updates at this point.
4. Job A updates the password table.
5. When Job A updates, Model 204 reads a current copy of the disk version of the password table into core. Because this copy was made after Job B's updates, it contains Job B's updates; therefore, Job A has access to Job B's updates. However, Job B does not have access to Job A's updates. Job B must update the password table again to get a current copy of the disk version of the password table data set.

Overview of the Password Expiration feature

The Password Expiration feature enhances the Model 204 CCASTAT security feature to manage password expiration and includes the changes described in this section.

Tracking the days a password is valid

The CCASTAT file saves password expiration and invalid logon count data for each user ID.

• PWDEXP is a view-only parameter that reflects the number of days a user can login using the same password. The password expires when the period of time elapses since the password was last changed.
• PWDPURGE is a view-only parameter that reflects the number of days an expired user ID is held in suspension in the CCASTAT file awaiting a new password from the system manager before the user ID is deleted.
• PWDWARN is a view-only parameter that reflects the number of days prior to password expiration that the user will receive the following warning at login:

  ***M204.2634: YOUR PASSWORD WILL EXPIRE IN n DAYS

For each user login ID requested, the LOGLST command displays:

• Password expiration date
• Password purge date
• The number of unsuccessful login attempts made

Revoking passwords and suspending user IDs

Model 204 immediately revokes a password after three, sequential, unsuccessful login attempts. A successful login after the first or second failure resets the error counter to zero for that user ID.

When a password is revoked, the user ID is held in suspension in the CCASTAT file and cannot login to Model 204. The system manager may reinstate that user ID by changing the password before the expiration date and the purge date have passed.

When the number of failed login attempts exceeds the number specified by the LOGTRY parameter, the action specified by the LOGFAIL parameter is taken. This is independent of the Password Security feature. If LOGTRY is set to 1 and LOGFAIL is set to 2, for example, the user's thread is deactivated on the second consecutive login attempt, but the user's password is not revoked until after three consecutive failed login attempts.

Deleting CCASTAT entries

An entry in CCASTAT is deleted when the password has expired and the grace period specified by the PWDPURGE parameter has elapsed. The system manager must create a new entry for that user ID.

• If the Online is running continuously from before midnight till the time a user logs in, the first user to login after midnight triggers the purge of all expired passwords that passed the grace period. A user who logged in before midnight does not trigger the purge; the trigger is a new login after midnight.
• If the Online has not been running continuously between midnight and an expired-and-past-the-grace-period user ID attempts to logon, only that user ID is deleted.

Whenever a user ID and password are deleted from the CCASTAT file, the following message is sent to the audit trail:

*** M204.2636: USER username DELETED FROM PASSWORD TABLE: PASSWORD EXPIRED

Defining a password

A new password must differ from the current and previous password for that user. A password cannot match the value of the corresponding user ID. See LOGCTL command: Modifying user ID entries in the password table.

When a password is added or changed, confirmation is requested with the following prompt:

***M204.2633: RE-ENTER NEW PASSWORD

The system manager can specify passwords that do not expire using the NOEXPIRE keyword in the LOGCTL A and LOGCTL C commands.

FILE and GROUP passwords

Password security rules apply to only LOGON passwords.

Create a backup copy of CCASTAT

The CCASTAT file used as a testing version should not be your production version. Before testing begins, put a backup copy of your CCASTAT file in a secure place. You and Technical Support might need the unconverted version of your file to diagnose a problem.

Capturing diagnostic data

Create a process by which you can capture and deliver debugging materials, such as audit trails, snaps, and dumps to Rocket Software in the event that Technical Support needs to help you diagnose problems during testing.

Increase in CCASTAT

The Password Expiration feature requires an additional eight bytes per user ID record in the password table. The increase in size is required only for user entries, not file or group entries. You would only have to increase the size of the CCASTAT file, therefore, if the file is almost full or you have a very large number of user entries. The increase might be necessary depending upon the current size of CCASTAT.

Understanding the ZCTLTAB utility

The ZCTLTAB utility is a dual purpose job that can be run to read an existing CCASTAT and create a new one pointed to by ddname in JCL NEWSTAT. Also, the ZCTLTAB JCL can be modified, removing the NEWSTAT, and just be used to change values of WARN, PURGE, and/or EXP in an already existing converted CCASTAT.

Updating CCASTAT using the Password Expiration feature

When you run the ZCTLTAB utility against the original unconverted CCASTAT file, it creates a copy of the original file and installs the Password Expiration feature into the new file. The new file is no longer compatible with earlier versions of Model 204. Therefore, Rocket Software strongly recommends that you save the original unconverted CCASTAT file. Also, use this new CCASTAT file with the Password Expiration feature in testing until you are completely satisfied that it is ready for production work.

After you have initially installed the Password Expiration feature in a CCASTAT file, you may run the ZCTLTAB utility against this file to update the password expiration parameters. ZCTLTAB will detect that CCASTAT has already been converted and will not create a new file, but will update the parameters in the existing file. When running with a converted CCASTAT file, the NEWSTAT data set is not required.

The first time a job runs with a CCASTAT file converted by ZCTLTAB, the creation date for all existing user IDs are reset to the current date.

The Online changes the creation date of a user entry in the CCASTAT file that is enabled for the Password Expiration feature whenever you change the password for that user.

Setting the security parameters

The ZCTLTAB utility uses the following input parameters:

• EXP to set the number of days until the password expires.
• PURGE to set the number of days until an expired password is deleted from CCASTAT.
• WARN to set the number of days prior to expiration to start warning the user.

Displaying the security parameters

These values are set within the CCASTAT file. Use the following VIEW command to view the:

• EXP value

  VIEW PWDEXP

• PURGE value

  VIEW PWDPURGE

• WARN value

  VIEW PWDWARN

Changing the values of the security parameters

To change the parameter values, your site simply runs ZCTLTAB with new values for EXP, PURGE, and/or WARN. If you change only one parameter value, the other parameter values remain as they were. Running the ZCTLTAB utility a second time (or more times) does not reset the creation dates of the entries, as the first run did.

ZCTLTAB condition codes

The following condition codes are feedback from the ZCTLTAB utility.

Condition code	Meaning
0	Success
4	Unable to open a file
8	Invalid parameters
12	The version of CCASTAT you used is too old
16	I/O error occurred when reading or writing a file
20	Unable to obtain storage (z/VSE only)

No changes are made to the CCASTAT file if the condition code is other than 0.

The ZCTLTAB utility writes a message to the CCAOUT data set that explains the condition code or an error. See "ZCTLTAB messages" in the Rocket Model 204 Messages Manual.

Running ZCTLTAB to update CCASTAT

The ZCTLTAB utility is unloaded during installation and is used to convert and maintain the CCASTAT file. You can reset the Password Expiration parameters EXP, PURGE, and WARN. This updates your current CCASTAT file and the CCAOUT file to capture the Password Expiration error messages.

Sample JCL for z/OS ZCTLTAB utility

//ZCTLTAB JOB (system manager),'system manager ',CLASS=A,MSGCLASS=A //******************************************************************** //* Job: ZCTLTAB created on: 22 NOV 2009 AT: 16:18:10 //* OPTIONAL Job to create/update CCASTAT with expiration passwords //* Updates password expiration parameters in CCASTAT //* 1. Initializes the password expiration feature in CCASTAT if //* it was not previously converted //* 2. Changes password expiration parameters in CCASTAT //* that have already been converted //* Include the NEWSTAT DD card only when running ZCTLTAB on a //* CCASTAT file for the first time. //* Notes: //* Add jobcard and modify parameters on EXEC card to set days till //* Expiration, start of Warning messages, and length of grace //* period before the password is Purged. Change DSNs for //* LOADLIB and the target CCASTAT. If NEWSTAT is used, modify //* new data set parameters as needed. //******************************************************************** //* Notes: //* May be run to convert and maintain CCASTAT to support //* expiring passwords. Read Install Guide and job comments //******************************************************************** //CONVERT PROC SYSINDX='M204',RLSE=V610n, // DISK=nnnn,VOLSER=nnnnnn //ZCTLTAB EXEC PGM=ZCTLTAB,PARM='EXP=20,WARN=19,PURGE=255' //STEPLIB DD DSN=M204.V610n.LOADLIB, // DISP=SHR //CCASTAT DD DSN=&SYSINDX..&RLSE..CCASTAT,DISP=SHR //NEWSTAT DD DSN=&SYSINDX..&RLSE..NEW.CCASTAT, // DISP=(,CATLG,DELETE), // SPACE=(TRK,25), // UNIT=&DISK, // VOL=SER=&VOLSER //CCAOUT DD SYSOUT=* // PEND //SECURE EXEC CONVERT // /* End of ZCTLTAB *******

Sample JCL for z/VSE ZCTLTAB utility

// JOB ZCTLTAB * ******************************************************************** * Computer Corporation of America * 6/09 * ******************************************************************** * ZCTLTAB creates and maintains the converted CCASTAT: (NEW/CCASTAT)* * ******************************************************************** /* Job: ZCTLTAB Created: Sept. 2009 * /* 1. Creates a new CCASTAT from a standard CCASTAT, copying in * /* security information and setting initial expiration values.* /* 2. Changes password expiration parameters in a CCASTAT * /* that has already been converted. * /* Include the NEWSTAT DD card only when creating a converted * /* CCASTAT file. To maintain a converted CCASTAT, remove NEWSTAT.* /* ******************************************************************* /* Notes: * /* Add jobcard and modify parameters on EXEC card to set * /* n_days till Expiration, start of Warning messages, * /* and length of grace period before the password is Purged. * /* Change DSNs for LOADLIB and the target CCASTAT. * /* If NEWSTAT is used, modify new data set parameters as needed. * /* * /* ****************************************************************** // EXEC PROC=M204JCL DLBL for JCL sublibrary // LIBDEF PROC,SEARCH=M204LIB.V610n // EXEC PROC=M204V610 DLBL for M204 library // LIBDEF PHASE,SEARCH=M204LIB.V610n // DLBL CCASTAT,'M204.CCASTAT',99/366,SD // EXTENT SYSnnn,volser,,,start,length /* NEWSTAT DLBL required only if creating new converted CCASTAT /* To update an existing CCASTAT supporting expiring passwords, /* remove or comment out the NEWSTAT JCL // DLBL NEWSTAT,'M204.EXPIRE.CCASTAT',99/366,SD // EXTENT SYSnnn,volser,,,start,length // EXEC ZCTLTAB,SIZE=AUTO,PARM='EXP=n_days,WARN=n_days,PURGE=n_days' /* /&

Using ZCTLTAB to modify CCASTAT

When you run ZCTLTAB to update an already-converted CCASTAT data set, follow the comments in ZCTLTAB to remove references to the NEWSTAT data set.

Note: If this data set is not omitted in subsequent execution, an empty reference file may be created.

Setting EXP, PURGE, and WARN in the ZCTLTAB utility

The valid values of EXP, PURGE, and WARN are from 0 to 255.

In the initial run of the ZCTLTAB utility to convert the CCASTAT file, you must explicitly set the EXP parameter.

Setting EXP=0 results in the expiration of all passwords in the CCASTAT file, unless they have the NOEXPIRE option. Only user IDs with the NOEXPIRE option will be able to login.

Setting EXP=0 is valid only if WARN=0 is also set or currently exists in a converted CCASTAT.

Viewing the ZCTLTAB parameters

If you issue a VIEW command for PWDEXP, PWDPURGE, and PWDWARN and they display a value of -1, CCASTAT has not been converted, and Model 204 logins behave as they did prior to installing the Password Expiration feature.

System manager's responsibilities

In a security emergency, the system manager can change the expiration of all passwords for all jobs accessing a CCASTAT file without bringing those jobs down by running the ZCTLTAB utility.

For a running job to read the updated copy of CCASTAT, the job must make a change to CCASTAT in one of the following ways:

• LOGCTL A command
• LOGCTL C command
• A valid user ID attempts to log in; the user ID is in the password table, but did not enter the correct password.
• The job notices that midnight has passed and finds user IDs to delete after a login is attempted. Model 204 notices when midnight passes and deletes expired passwords when the first user of the day attempts to logon.

PWDEXP, PWDPURGE, and PWDWARN are view-only parameters in Online and Batch204 runs. The only way to change the values is with the ZCTLTAB utility designated by EXP, PURGE, and WARN. Every job that runs with that CCASTAT file from then on will use those values.

Note: Any user who is authorized to submit the ZCTLTAB job can reset the EXP, PURGE, and WARN values. Rocket Software recommends storing this job in a secured data set.

Supporting password expiration at your site

The ZCTLTAB utility checks whether the EXP utility parameter is not zero when the WARN utility parameter is not zero. If the EXP parameter is set to zero when WARN is not set to zero, a Return Code of eight (8), meaning invalid parameter, is invoked.

CCASTAT may be shared between multiple Online and Batch jobs, as in previous versions.

If the ZCTLTAB utility is not run, then the value -1 is displayed for the PWDEXP, PWDPURGE, and PWDWARN parameters, when you issue a VIEW command against them. There is no password expiration and no warning of impending expiration.

Deleting a user ID

After a password expires, the password and user ID are deleted from the system when the PWDPURGE number of days has elapsed. The audit trail automatically records deleted user IDs.

For Onlines that do not run over midnight, a user whose password has expired past the purge period is deleted from CCASTAT when that user attempts to login. It does not occur when another user logs in.

Defining passwords

Follow the instructions for defining passwords listed in LOGCTL command: Modifying user ID entries in the password table.

• If you do not run the ZCTLTAB utility, you can apply the lesser restrictions.
• After you run the ZCTLTAB utility, you must use the more detailed restrictions.

Changing and reusing passwords

After you run the ZCTLTAB utility, when passwords are changed, they cannot be a repeat of:

• The current password
• The previous password
• The value of USERID

Waiting to change a password

Users waiting to update CCASTAT with a new password simply wait until CCASTAT is available. The wait type is 23. In previous versions of Model 204, when a user was changing a password, then another user attempting to do the same simultaneously received the following message:

***M204.0370: TABLE IN USE, TRY AGAIN

Now bumpable, swappable waits replace the message. For updating users, the message is eliminated.

Password from a trusted environment

No password expiration verification is done for logins from trusted environments, which is the behavior of previous versions of Model 204.

CCASTAT backwards compatibility

Prior versions of Model 204 cannot run with the CCASTAT file created for V6R1.0. This backward incompatibility is present when the parameters that control password expiration have been used in a run that has Read-Write access to the CCASTAT file.

The system manager should save the original, unconverted CCASTAT file. Once a CCASTAT file is converted for this version, previous versions of Model 204 can open and look at, but not run with, the converted CCASTAT. Doing so results in the message:

M204.0337: Wrong version for CCASTAT - hexVersion

Managing CCASTAT messages

When you begin using the Password Expiration feature there is a greater likelihood of CCASTAT enqueue conflicts, because Model 204 is looking at CCASTAT for more information, so it holds enqueue longer. Also, because of password expirations, CCASTAT is updated more frequently.

You might see the following or other messages that reveal enqueue conflicts:

M204.0196: Data set datasetName used by ddName DD statement currently in use M204.0344: Disk version of CCASTAT changed by job jobName yy.ddd hh:mm