Model 204
V5R1 RESTART Recovery: Major Enhancements, Part 3 By James Damon
Processing RESTART Recovery with Constraints Prior to V5R1, you could not separate the two phases of RESTART recovery. Although you could run the ROLL BACK phase only, you could not run the ROLL FORWARD phase as a separate process.
Also, prior to V5R1, the following command invoked the ROLL BACK phase, but once complete, you could not reissue the same command.
RESTART ROLL BACK
Similarly, if you chose both ROLL BACK and ROLL FORWARD processing, as in the following command, once processing completed, you could not subsequently issue the following command or the previous command.
RESTART ROLL BACK ERROR CONTINUE ROLL FORWARD
Introducing RERUNRB – the Flexible RESTART Command Option These constraints were removed in V5R1. Now you can rerun, back-to-back or separately, either phase of recovery until all files are recovered and all problems resolved. This may be required, for example, when a file is omitted from the first attempt at recovery and this omission is recognized prior to performing any updates against the file. For example, you might have run the following command, which completed successfully.
Then you notice the following messages in CCAAUDIT:
The messages mean that recovery completed successfully on all files that were allocated to the run, except the HISTORY file. You had to recover the HISTORY file by other means.
Under V5R1, the entire recovery process can be rerun any number of times, starting with using the RERUNRB option on the RESTART command, as shown in the following command.
RESTART RERUNRB
Looking at the Details of the RERUNRB Option The RERUNRB option is mutually exclusive with all other options and must be the only option specified. Otherwise, you may see the following message:
Although you can issue a RESTART RERUNRB command at any time, usually it is run after one of the following commands:
Since the RERUNRB option reruns only the ROLL BACK phase of RESTART processing, you will probably decide to submit another recovery run that includes one of the following RESTART commands, upon successful completion of RERUNRB processing:
When one of these commands completes successfully, it signifies that all updates have been reapplied up to the point of failure and any uncommitted transactions have been backed out.
In Summary The ability to run ROLL BACK or ROLL FORWARD processing separately and to repeat the entire recovery process until all problems are resolved provides the ease and flexibility system managers require when recovering the system from unforeseen events.
System 1032
Lesser Known Features: Part 7 By Tym Stegner
In this article for CCAPRINT, we start looking at commands and options that comprise System 1032 security. From the System 1032 User’s Guide, Module 3, Ensuring System 1032 Security, comes the definition of the System 1032 security concept:
System 1032 security commands--ADMIT and PREVENT – let you set access restrictions on an entire catalog, or control access to attributes, forms, procedures, record descriptors (RDs), and records individually.
Briefly, the PREVENT command locks the door against entry or access. The PREVENT command is the access limiting command.
Note: An ADMIT command is irrelevant until a PREVENT command has been applied.
The creator or owner of a catalog automatically has complete access to that catalog. The system variable $SITE_DBA can specify a user name that also has owner-level access. It is as if no System 1032 security exists for those users.
Understanding the Access Types System 1032 security commands use access types to define the level of restriction and the access that is to be set on the specified objects. The access type determines the activity a user can perform on the object. The following chart lists the access types, the objects under their control, and what sort of control occurs.
Access Hierarchy With the exception of the OPEN, ADD, and DELETE access types, the access types follow a hierachy of restriction from most (1) to least (5).
MODIFY
The hierachy is handled differently for the PREVENT and ADMIT commands.
The PREVENT command restricts a specified access that automatically includes all preceding access types in the hierarchy.
For example, issuing a PREVENT READ command automatically imposes CHANGE and MODIFY access. Users will have only SHOW and EXECUTE access to the object. Whereas, issuing an ADMIT READ command automatically grants SHOW and EXECUTE access.
To use the access types, OPEN, ADD, and DELETE, you must issue individual security commands to restrict or grant access, as they are not part of the hierarchy.
Applying Security Ideally, when the catalog is designed, a security plan is created as part of the design process. However, you can apply security commands to a catalog at any time after it is created--even while the catalog is in use. Users, who already have the catalog open when the security commands are applied, are not affected by new security until after they close the catalog. To prevent catalog changes until new security is applied, you can issue a LOCK ON NO_ACCESS command to prevent changes, then release the lock via LOCK OFF command when the security is in place.
As new PREVENT commands do not override existing ADMIT commands, you can increase security for objects by giving an ADMIT CLEAR command for those objects, then specify new ADMIT commands that make the objects less accessible to users or groups.
Security commands are cumulative; you can add or remove security commands, if suitably enabled, at any time. You can clear all the System 1032 security and start over again, if necessary. Only the owner of a catalog can specify security commands. After a catalog is created, if desired, the owner can shift the ownership to another user using the MODIFY DATASET OWNER command.
If journaling is enabled for a catalog, the security commands are tracked. Use the SHOW JOURNAL command to see if journaling is active. If so, you should disable journaling by issuing a MODIFY NO JOURNAL command or start a new journal file using the SAVEPOINT PURGE command before applying new security. This prevents a future recovery event from rolling a catalog back to a previous security state.
Security commands do take up space in the catalog. A catalog with extensive applied security or that must apply security to many users opens more slowly than a catalog with a simpler security scheme. Take this into account when you design your security plan and take advantage of the various methods for controlling access.
Checking and Reapplying Security You can issue a SHOW SECURITY command to examine the existing security access on a catalog. If you are not the owner or $SITE_DBA, only the restrictions and privileges on the catalog that apply to you are displayed.
You can use the output of a SHOW SECURITY command to reapply existing security during a catalog rebuild. If you capture the security to a file via a SHOW ON filespec command, the resulting file can be used to reapply the existing security.
Security Groups The ADMIT command can manage access by specifying individual users or groups of users, who must identify themselves or be denied access. The following lists possible identification schemes available.
VMS Identifier or VMS Identifier with password
If a password is specified in an ADMIT command, it must be specified using the PASSWORD option on the OPEN command.
If a password is defined for a particular security class, any user who specifies that password gains that security access. If the password is defined as part of a USERNAME or UIC class, only that username or a user with a matching UIC can receive the access, and then only if the password is supplied in the OPEN command.
Appropriate ADMIT commands can provide different levels of access by specifying different passwords at OPEN time.
Note: Only a single password can be specified in any OPEN command, so your security plan must ensure that the particular password provides the necessarylevels of access.
In Summary This can be helpful when different classes of users need see only selected attributes in the dataset, or need execute certain procedures against that dataset. Restricted users will never even see such restricted objects.
Coming Attractions The next article regarding security in System 1032 addresses more granular security. While much of the time security is provided at the catalog level, it is also possible to apply security to objects within a catalog. Individual attributes can have their own security levels separate from the dataset they reside in, as can individual RDs, forms, and procedures defined either in a dataset, database or library.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
